[Esapi-dev] Bug 141
Chris Schmidt
chrisisbeef at gmail.com
Wed Nov 3 15:34:18 EDT 2010
Lee -
It looks like the basic idea here is that we have a blocking deque that is
being used essentially as a Stack.
So in other words, a request comes in we get the existing deque off of the
session (or create a new one if there isn¹t one yet)
We then push the time of the current request (in ms) onto the head of the
stack.
We then examine the tail of the stack looking for requests older than
whatever the maximum threshold is and remove them from the tail of the
stack.
Once we are done maintaining the stack, we check the size of the stack and
if it exceeds the maximum threshold of requests/time then we error the
request.
Does this sound like the basic idea?
We could easily do this (using a Queue) in Java 5 without adding the
additional dependencies using a LinkedBlockingQueue
Request comes in, do same logic check session for existing queue, if
absent create a new one
Push the time in MS onto the tail of the queue
Peek and Remove from the head of the queue for anything older than the time
threshold
Check size of queue and if it exceeds the max threshold of requests/time
then error the request...
This achieves the same logic, with a minimal hit to performance and keeps it
thread-safe without having to add external synchronization or locking.
Notice that basically all we did was flip the Stack from Lee¹s
implementation into a Queue so it is still a FIFO collection, just the head
and tail are reversed from the Deque implementation. Also generally
speaking, since you are not retrieving and pushing onto both ends of the
Collection I¹m not sure it makes sense, and could possibly even be a bit
of a performance hit to use a Deque in this case (although that is largely
speculation on my part it may be a NIL effect on performance, but
definitely seems odd to use a double-ended collection if you are only
working one-way)
The only real benefit I see to using the LinkedBlockingDeque is this
statement from the API Docs:
³Most operations run in constant time (ignoring time spent blocking).²
However, I think that this would be a negligable performance difference due
to the environment containers are multi-threaded but since we are dealing
with information local to a specific session, I think it is pretty much an
impossibility that you would be able to generate enough simultaneous traffic
on a single session that this would become an issue.
Thoughts?
On 11/3/10 7:34 AM, "Jim Manico" <jim.manico at owasp.org> wrote:
>> > I seem to remember the same statement being made about the concurrency
>> API in 1.5 over 1.4 :D
>
> Indeed, about 8 years ago. I think we need to move forward, though. The need
> for thread-safety is a much more prolific concern today than it was the last
> time the API's changed.
>
> In general? 1.6 is freaking awesome. It almost ends the need for sloppy
> frameworks like Struts and Spring. It really ties things together. I'm
> considering starting a new version of ESAPI that is pure 1.6. It's stellar.
> Anyone interested?
>
> Lee, et al, do you agree with these conjectures?
>
> - Jim
>
>
>> Re: [Esapi-dev] Bug 141 I seem to remember the same statement being made
>> about the concurrency API in 1.5 over 1.4 :D
>>
>> I will take a look at the patch today and also take a look at the port.
>>
>>
>> On 11/3/10 2:58 AM, "Jim Manico" <jim.manico at owasp.org> wrote:
>>
>>
>>> But this is not a third-part dependency - it's a port from Java 1.6 to
>>> Java 1.5, so I feel a lot better about it.
>>>
>>> Lee - what kind of changes would we need to make to your patch for a
>>> "pure" Java 1.5 patch?
>>>
>>> Chris - we may want to consider using the 1.6 concurrency API for all of
>>> ESAPI. It's stellar - and way ahead of 1.5.
>>>
>>> - Jim
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> If there is any way to do it without adding another dep I would much
>>>> prefer that route. I will try to take a look at this proposed patch
>>>> tomorrow
>>>>
>>>> Sent from my iPwn
>>>>
>>>>
>>>> On Nov 2, 2010, at 11:37 PM, Jim Manico <jim.manico at owasp.org> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> Lee,
>>>>>
>>>>> Using the back-port of JSR166 for JDK 1.5 will mean a new jar dependency
>>>>> ( http://gee.cs.oswego.edu/dl/concurrent/dist/jsr166.jar ) and only for
>>>>> users of this one filter.
>>>>>
>>>>> Franky, I''m in favor of this - since this dependency will go away once
>>>>> we migrate to Java 1.6. This is also a much better concurrency framework
>>>>> than what exists in Java 1.5 and we may want to consider using JSR166 a
>>>>> great deal more in ESAPI 2.0.
>>>>>
>>>>> So I say, yes, but it's a controversial yes and I'd like other ESAPI
>>>>> dev's to chime in before we commit this change.
>>>>>
>>>>> Thoughts folks?
>>>>> - Jim
>>>>>
>>>>> PS: Lee? You "Rock" :) thanks for this contribution.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Jim,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Would it be possible to use the back port of JSR166 for Java5? :-
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://sourceforge.net/projects/backport-jsr166/files/backport-jsr166/3.1
>>>>>> /backport-util-concurrent-Java50-3.1.zip/download
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Lee
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: Jim Manico [mailto:jim.manico at owasp.org]
>>>>>> Sent: Tuesday, 2 November 2010 9:06 p.m.
>>>>>> To: Lee Warren Gilbert; ESAPI-Developers
>>>>>> Subject: Bug 141
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://code.google.com/p/owasp-esapi-java/issues/detail?id=141&sort=miles
>>>>>> tone
>>>>>>
>>>>>> Lee,
>>>>>>
>>>>>> Your patch for the RequestRateThrottleFilter is excellent (and
>>>>>> necessary). Would you consider tossing us a Java 1.5 version? We have not
>>>>>> migrated to 1.6 yet, sir.
>>>>>>
>>>>>> Thanks for your donation, and thanks for considering making another
>>>>>> pass at this.
>>>>>>
>>>>>> Cheers,
>>>>>> Jim
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Esapi-dev mailing list
>>>>> Esapi-dev at lists.owasp.org
>>>>> https://lists.owasp.org/mailman/listinfo/esapi-dev
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-dev/attachments/20101103/b145e51b/attachment.html
More information about the Esapi-dev
mailing list