Still not sure I understand. If the service is async, it probably already has a bound on number of requests it can handle, right? At some level, you can get more requests than it can handle. With that, you will have to somehow provide some sort of buffer layer. I guess you could push this configuration into shiro, but you will still have to manage it in your application.
That is, it seems like it would be easier to take that into your domain as early as possible. Your authentication realm will simply block for as many requests as your executor can take, if it hits the limit, it starts returning unauthenticated. Right? On Jan 20, 2014 11:21 AM, "gcollins" <[email protected]> wrote: > Josh Berry wrote > > On Thu, Jan 16, 2014 at 5:14 PM, gcollins < > > > gareth.o.collins@ > > > >wrote: > > > >> Hello Les, > >> > >> Thankyou very much for the answer! > >> > >> Yes I could do that but it doesn't really solve my problem. When > requests > >> for authentication spike, I would either need to allocate a large number > >> of > >> threads for the ExecutorService thread pool...or slow down > authentication > >> for users by queueing the requests up (the authentication request could > >> take > >> several seconds to complete). > >> > > > > I'm curious on how this wouldn't be the case for any asynchronous > > approach. > > The underlying custom authentication mechanism itself is asynchronous. Only > trying to keep > to existing Shiro interfaces would force me to hold threads. > > thanks, > Gareth > > > > > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/Asynchronous-Authentication-tp7579507p7579536.html > Sent from the Shiro User mailing list archive at Nabble.com. >
