[Esapi-user] [Esapi-dev] Bug 141

Jim Manico jim.manico at owasp.org
Thu Nov 4 03:26:01 EDT 2010


Chris,

Epic + Awesome analysis. I'm very curious to Lee's thoughts on your 
comments.

If we cannot fix this filter before 2.0GA, then I'd like to drop it from 
the codebase, add it to Google code, and fix it for 2.0 GA. It's 
"broken" as is.

- Jim

> 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=milestone
>                         <http://code.google.com/p/owasp-esapi-java/issues/detail?id=141&sort=milestone>
>
>                           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-user/attachments/20101104/77dd4288/attachment.html 


More information about the Esapi-user mailing list