[prev in list] [next in list] [prev in thread] [next in thread]
List: forgerock-openam
Subject: [OpenAM] look into the session table
From: frederic.vandevelde () paradigmo ! com (frederic Van De Velde)
Date: 2010-11-29 8:35:49
Message-ID: EB39FD3E-1CB6-486E-ADC8-B2A2C464E9CE () paradigmo ! com
[Download RAW message or body]
Steve,
I have multiple agents, here is the configuration of one apache where I run agent \
3.0-01:
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 100
I see that I have currently 11 apache processes and on one opensso instance I have 11 \
connections but I also have 3 connection on another opensso instance which make no \
sense. Yesterday I cleaned-up all connections of the this agent and restarted the \
agents to have a clean situation but it seems that it's already create zombie \
connections.
I also have another agent for which I did a cleanup yesterday and it has already more \
than 120 connections on two different opensso instances ! This agent is still a 2.x \
agent running on apache 2.2.14, the agent id is used by two components, one in the \
DMZ and one internally but I only have 6 httpd processes for the internal server and \
12 for the dmz server.
Regards,
Frederic.
On 29 Nov 2010, at 08:37, Steve Ferris wrote:
> If the Agent's are not crashing then their must be a different cause, how many \
> agents do you have and how many worker processes/threads per server?
> Steve
>
> --
> Steve Ferris : ForgeRock AS : e: steve.ferris at forgerock.com
> t: +44 (0)7813 709285 f: +44 (0)7971 042421 w: forgerock.com
> OpenAM, the new name for OpenSSO
>
> On 28 Nov 2010, at 2:50pm, frederic Van De Velde wrote:
>
> > Alan,
> >
> > I have set the "com.sun.identity.session.returnAppSession=true" parameter so I \
> > should also see all agent sessions and I actually see them in the console.
> > Most of my agents have this version:
> >
> > all: Version: 3.0-01
> > all: Build Date: Wed Jun 16 22:36:56 PDT 2010
> > all: Build Machine: flashy
> >
> > And they aren't crashing at all ...
> >
> > I also noticed that I have more sessions from agents located in the DMZ so behind \
> > the firewall, could it be related ? Is there a keepalive to be set in the \
> > configuration so the connection doesn't get dropped by firewall while it is \
> > inactive for some time ?
> > Is it also possible that the console doesn't show up more than 120 connections at \
> > a time because I have noticed that if I search for all connections on a specific \
> > agent I get only 120 connections then I start to invalidate them and the number \
> > of connection stay on 120 then at one moment it begin to decrease.
> > Regards,
> > Frederic.
> >
> > On 27 Nov 2010, at 16:20, Allan Foster wrote:
> >
> > > Frederic
> > >
> > > Have a look in your apache log file, and see if you are getting any crashes in \
> > > there.
> > > Agent sessions are not shown on the console list.
> > >
> > > If your apache subprocesses are crashing... that might be a cause.
> > >
> > > What version of teh agent are you running on the apache server?
> > >
> > > Allan
> > >
> > > On 11/27/10 22:17, frederic Van De Velde wrote:
> > > >
> > > > Hi,
> > > >
> > > > Still with my increasing number of session problem, I now have 120 sessions \
> > > > active on one instance (including app sessions) which seems normal but in the \
> > > > statistics file I have this:
> > > > Max sessions in session table Current/Peak:462/467
> > > > Max active sessions Current/Peak:462/462
> > > > Session Notifications in Queue Current/Peak:0/0
> > > >
> > > > How can we explain that there is a difference between the number of sessions \
> > > > seen by the console and the number of sessions seen by the statistic routine \
> > > > and what are these sessions ?
> > > > Regards,
> > > > Frederic.
> > > >
> > > > On 25 Nov 2010, at 20:38, Steve Ferris wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > My guess as to what is happening is the Apache sub processes are quitting \
> > > > > for some reason leaving their application tokens active, each request will \
> > > > > create a new token.
> > > > > regards
> > > > > Steve
> > > > >
> > > > > --
> > > > > Steve Ferris : ForgeRock AS : e: steve.ferris at forgerock.com
> > > > > t: +44 (0)7813 709285 f: +44 (0)7971 042421 w: forgerock.com
> > > > > OpenAM, the new name for OpenSSO
> > > > >
> > > > > On 25 Nov 2010, at 5:56pm, frederic Van De Velde wrote:
> > > > >
> > > > > > Steve,
> > > > > >
> > > > > > I have set the max number of sessions on 10000 which is already 2 times \
> > > > > > what we have but I also need a restart for this to be active.
> > > > > > Now that I have set the "com.sun.identity.session.returnAppSession=true" \
> > > > > > parameter on the dev server I see more informations. When I first use the \
> > > > > > application it creates 7 connexions with the agent profile as userid but \
> > > > > > more strange the max session time is set to a very high value \
> > > > > > (2562047788015215)
> > > > > > Each time I logout/login it create again 6 more connexions so I think I \
> > > > > > found my session problem but why it is behaving like that ?
> > > > > > The agent is an apache 2.2 agent 3.0-01 on solaris sparc 32-bit, it's the \
> > > > > > latest build from oracle, I tried using the ForgeRock agent but I have \
> > > > > > problem (see my other thread in this mailing list).
> > > > > > Is this a normal behavior of the agent ?
> > > > > >
> > > > > > Regards,
> > > > > > Frederic.
> > > > > >
> > > > > > On 25 Nov 2010, at 17:53, Steve Ferris wrote:
> > > > > >
> > > > > > > 100,000 is fine, providing you have enough memory. 100,000 would be \
> > > > > > > about 2G heap leaving some headroom.
> > > > > > > Steve
> > > > > > >
> > > > > > > --
> > > > > > > Steve Ferris : ForgeRock AS : e: steve.ferris at forgerock.com
> > > > > > > t: +44 (0)7813 709285 f: +44 (0)7971 042421 w: forgerock.com
> > > > > > > OpenAM, the new name for OpenSSO
> > > > > > >
> > > > > > > On 25 Nov 2010, at 4:47pm, Chee Chong wrote:
> > > > > > >
> > > > > > > > Frederic,
> > > > > > > >
> > > > > > > > You can definitely push the figure higher if you have properly tune \
> > > > > > > > your systems hosting the OpenAM. 100,000 is definitely far too high. \
> > > > > > > > Your JVM can't hold that many sessions. 10,000 is a pretty good \
> > > > > > > > number. I have done that in Production before.
> > > > > > > >
> > > > > > > > --
> > > > > > > > Chee Chong
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On 11/26/10 12:43 AM, frederic Van De Velde wrote:
> > > > > > > > >
> > > > > > > > > Steve,
> > > > > > > > >
> > > > > > > > > Seems I have to restart for the parameter to be active, I did it on \
> > > > > > > > > the dev instance and it's already showing more information. I'll \
> > > > > > > > > prepare it on the prod servers and will wait for the next restart.
> > > > > > > > > Currently we have to restart each instances every two day which is \
> > > > > > > > > a pity because the opensso server are used about 20 hours a day. \
> > > > > > > > > What would be the impact of setting the number of sessions to a \
> > > > > > > > > very high number like 100000 for example ?
> > > > > > > > > Thank you,
> > > > > > > > > Frederic.
> > > > > > > > >
> > > > > > > > > On 25 Nov 2010, at 17:28, Steve Ferris wrote:
> > > > > > > > >
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > You can set this property under configuration / servers and sites
> > > > > > > > > >
> > > > > > > > > > com.sun.identity.session.returnAppSession=true
> > > > > > > > > >
> > > > > > > > > > Under the session tab you should see all operational sessions. If \
> > > > > > > > > > that doesn't help, we would have to write some custom code.
> > > > > > > > > > regards
> > > > > > > > > > Steve
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Steve Ferris : ForgeRock AS : e: steve.ferris at forgerock.com
> > > > > > > > > > t: +44 (0)7813 709285 f: +44 (0)7971 042421 w: forgerock.com
> > > > > > > > > > OpenAM, the new name for OpenSSO
> > > > > > > > > >
> > > > > > > > > > On 25 Nov 2010, at 4:19pm, frederic Van De Velde wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > We have a problem with the session table constantly filling up \
> > > > > > > > > > > until it is completely full. In the statistics \
> > > > > > > > > > > (amMasterSessionTableStats) we have this:
> > > > > > > > > > > Max sessions in session table Current/Peak:3782/3794
> > > > > > > > > > > Max active sessions Current/Peak:3775/3785
> > > > > > > > > > > Session Notifications in Queue Current/Peak:0/0
> > > > > > > > > > >
> > > > > > > > > > > When the number of session reach 5000 the server answer \
> > > > > > > > > > > "Maximum Sessions limit reached or session quota has exhausted" \
> > > > > > > > > > > but in the session tab of the console there are only few \
> > > > > > > > > > > sessions active.
> > > > > > > > > > > I have that on 4 different opensso instances, 3 of them are \
> > > > > > > > > > > behind an apache load balancer but they do not share any \
> > > > > > > > > > > session information. The 4th one serve as a dev instance but \
> > > > > > > > > > > has also the same problem.
> > > > > > > > > > > Is there an easy way to look into the session table an see what \
> > > > > > > > > > > are the details about those stuk sessions ?
> > > > > > > > > > > Regards,
> > > > > > > > > > > Frederic.
> > > > > > > > > > > _______________________________________________
> > > > > > > > > > > OpenAM mailing list
> > > > > > > > > > > OpenAM at forgerock.org
> > > > > > > > > > > https://lists.forgerock.org/mailman/listinfo/openam
> > > > > > > > > >
> > > > > > > > > > _______________________________________________
> > > > > > > > > > OpenAM mailing list
> > > > > > > > > > OpenAM at forgerock.org
> > > > > > > > > > https://lists.forgerock.org/mailman/listinfo/openam
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > OpenAM mailing list
> > > > > > > > > OpenAM at forgerock.org
> > > > > > > > > https://lists.forgerock.org/mailman/listinfo/openam
> > > > > > > > _______________________________________________
> > > > > > > > OpenAM mailing list
> > > > > > > > OpenAM at forgerock.org
> > > > > > > > https://lists.forgerock.org/mailman/listinfo/openam
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > OpenAM mailing list
> > > > > > > OpenAM at forgerock.org
> > > > > > > https://lists.forgerock.org/mailman/listinfo/openam
> > > > > >
> > > > > > _______________________________________________
> > > > > > OpenAM mailing list
> > > > > > OpenAM at forgerock.org
> > > > > > https://lists.forgerock.org/mailman/listinfo/openam
> > > > >
> > > > > _______________________________________________
> > > > > OpenAM mailing list
> > > > > OpenAM at forgerock.org
> > > > > https://lists.forgerock.org/mailman/listinfo/openam
> > > >
> > > >
> > > > _______________________________________________
> > > > OpenAM mailing list
> > > > OpenAM at forgerock.org
> > > > https://lists.forgerock.org/mailman/listinfo/openam
> > >
> > >
> > > --
> > > <ForgeRock-226x60.png> Allan Foster VP Technical Enablement
> > > e: allan.foster at forgerock.com
> > > t: +1.503.334.2546
> > > w: www.forgerock.com
> > > The New home for OpenSSO -- OpenAM! It's gonna be BIG!
> > > _______________________________________________
> > > OpenAM mailing list
> > > OpenAM at forgerock.org
> > > https://lists.forgerock.org/mailman/listinfo/openam
> >
> > _______________________________________________
> > OpenAM mailing list
> > OpenAM at forgerock.org
> > https://lists.forgerock.org/mailman/listinfo/openam
>
> _______________________________________________
> OpenAM mailing list
> OpenAM at forgerock.org
> https://lists.forgerock.org/mailman/listinfo/openam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.forgerock.org/pipermail/openam/attachments/20101129/ded90778/attachment-0001.html \
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic