We were doing approximately 800 operations (1 authenticate per operation) per second in a server type process functioning as a relay between a client and distributed database. With the ConcurrentMarkSweep GC turned on and a half gig of heap, after about 40 minutes of continuous hits, garbage collection would start going crazy, bringing it down to about 20operations per second and it wouldn['t recover. Taking out the authentication prevented this from happening. However, switching to the code Jared suggested seems to be just as effective. With all of those authentications creating so many HashMaps, it seems like it was doing a fair amount of object creation, hence the memory issues.
Also, thanks for the pointer to the DefaultSubjectDAO. I'm definitely working in a stateless space, so I'll look that over. John On Wed, Jan 16, 2013 at 9:26 PM, Les Hazlewood <[email protected]>wrote: > Hi John, > > I'm curious - what performance overhead did you see? > SimplePrincipalCollection is a simple wrapper around a > LinkedHashMap<String,Set> - was Map/Set construction slow? (I don't know > your application's performance threshold requirements, and I'm always > curious how to make things faster). > > Also, yes, I'll echo Jared's advice - you just need to call > subject.login(authcToken) - no need to construct anything prior. When you > turn on authentication caching, AuthenticationInfo instances (and their > internal PrincipalCollecition) are cached after creation and re-used while > they exist in cache. > > Also know that Shiro defaults to storing authentication state > (isAuthenticated, PrincipalCollection) in the Subject's Session. This is > however fully customizable and you can turn this off (for example, if > you're building a stateless application and/or framework). See the > DefaultSubjectDAO JavaDoc for more information. > > On Wed, Jan 16, 2013 at 1:44 PM, John Vines <[email protected]> wrote: > >> That seems a lot more performant. I guess all taht overhead of dealing >> with PrincipalCollections the principalled Subjects did it in. Thanks for >> your help. >> >> John >> >> >> On Wed, Jan 16, 2013 at 3:21 PM, Jared Bunting < >> [email protected]> wrote: >> >>> So, if I understand correctly, you are embedding the principal into the >>> AuthenticationToken (in the API call), then getting it out, building up >>> a Subject with it, then authenticating on that subject? >>> >>> My thought would be to do something like the following. >>> >>> AuthenticationToken authTok = api.convertToAuthToken(thriftToken); // >>> this should be a very simple conversion...grabbing a field or two, >>> parsing a string >>> >>> Subject subject = new Subject.Builder().buildSubject(); >>> subject.login(authTok); // if this is successful, the subject will be >>> populated with the PrincipalCollection >>> >>> Then, in your realm, you do that actual conversion from your >>> AuthenticationToken to your PrincipalCollection. It is important to do >>> it here, because this is where authentication caching happens. >>> >>> Does that make sense? Does it address your issues at all? >>> >>> HTH, >>> Jared >>> >>> On Wed 16 Jan 2013 11:42:46 AM CST, John Vines wrote: >>> > In our application, we have an API call which takes in a thrift based >>> > token, transforms it into the appropriate type of AuthenticationToken, >>> > pulls the principal out of it and creates a SimplePrincipalCollection >>> > with it, and uses that to build a Subject. I then do >>> > subject.login(token) with that subject to authenticate. However, we >>> > noticed in testing that the object creation from this process is >>> > killing performance. I changed it to keep a Map of thrift token -> >>> > Subject, and then utilize isAuthenticated() which seems to have >>> > alleviated the issue. >>> > >>> > However, I'm a bit miffed at the original performance issues, since I >>> > had set up Authentication caching. Is there a better way to just >>> > authenticate given a token, or is my way the right way? Additionally, >>> > I feel that caching a token->Subject is redundant with the >>> > authentication caching, so I don't know if there are better practices >>> > in this case as well. >>> > >>> > Thanks >>> > John >>> >>> >>> >> >
