User Login Sessions do not terminate..Please guide

[Former Member]

Hello All,

Am working on portal server = EP7 SP9

In the Visual Administrator if you navigate to <SID> -> server instance -> Services -> Security Provider -> Login Sessions.

This page gives you a list of all open user sessions.

I have noticed the following:

1. The user sessions do not expire until 2 days.

Example: If user logins into portal, a new session is created and I will see the logon-id, session creation and expiry timestamp.

The concern is about Expiry Timestamp wherein the user sessions stays open till close to 28 hours.

Secondly, there are a number of login sessions with principal as 'Guest'.

This does cause performance issues in portal as the memory allocated for user sessions is being released in time for other new user sessions.

Questions:

1. Is there a way to reduce the Expiry timestamp

2. We have not configured anonymous portal. So from where does user - Guest come from? Two things are running in my mind - either Guest is some service user or secondly some particular logon-id is not being caught.

3. If I manually terminate the user sessions(after learning that user is not working on portal anymore), till this cause issues.

4. During investigating the above I also noticed that one user login in portal at times creates 2-3 user sessions as 'Guest' which is shown in Login Sessions page.

Need your guidance on the above.

Awaiting Reply.

Thanks,

Ritu

[former_member192434]

sorry posted towice

[former_member192434]

Hi Ritu,

You can set the session timeout for the irj(which is the portal) application in the file \usr\sap\<SID>\j2ee\j2ee_01\cluster\server\services\servlet_jsp\work\jspTemp\irj\root\WEB-INF\web.xml

It will be 30 minutes,Change 30 to 10 or as you required.

<session-timeout>

30

</session-timeout>

After changing session time out restart your portal server.

thanks

[Former Member]

Thanks Anup.

Ive been reading a lot about this on SDN had read about this change you suggested.

But it seemed like this change will change the overall user session timeout but not the idle timeout.

In other words, this will force users to logout irrespective they are working in portal and their session is not idle.

Secondly, this will also cause the logon tickets to expire too.

I was looking towards more of idle session timeout.

I have read all the above on SDN itself. In case I have mis-understood this all please write back or better you share your expeirence when you made this change?

After making this change did you check its working in the Login Sessions page I mentioned in my post?

Awaiting Reply.

Thanks,

Ritu

[former_member192434]

Hi

Setting session timeout in web.xml only releases the current users session, which will then release all datas stored in this session. But this does not have any influence on users logon ticket, while the ticket validity is by default set to 8 hours in UME and with in this 8 hours every time a users session gets expired, a new session is created for the user on demand.

So the user is not logged off after session-timeout.

Check this for more:

thanks

[Former Member]

Anup,

Please check this link - http://help.sap.com/saphelp_nw04/helpdata/en/bd/6ca740aa053a13e10000000a155106/frameset.htm

Is this similar to what you are suggesting?

If yes, one doubt.

Our portal is configured on HTTPS, so will this change in web.xml be affective on https requests as well?

Secondly, the default value in web.xml session time is 30 minutes but the Login Sessions page shows 28 hours. Any thoughts on why this difference?

Awaiting Reply.

Thanks,

Ritu

[former_member192434]

Ritu,

As i suggested u my above post the session timeout in web.xml only releases the current users session, no matters. your portal is configured on HTTPS ...

Ans to your second question...might have changed some body on your side..while congiguring..as per as my knowdege the default time is 30 minutes is assumed.

thanks

[former_member192434]

sorry posted towice

[Former Member]

Thanks Anup.

Ill surely try this and write back.

Regards,

Ritu