BO 3.1: The session has been logged off or has expired. (FWM 01002)

[Former Member]

Hello,

We are experiencing persistent FWM 01002 errors when using BOXI 3.1 InfoView at random time intervals.

Here is the complete error:

An error has occurred: Unable to reconnect to the CMS bo.server.com:6400. The session has been logged off or has expired. (FWM 01002)

Details:

-This is a clustered environment: 2 Windows 2003 servers

-Using out of the box Tomcat for web/app

-New build, no upgrades

-Load balancer for 2 web servers

We have upped all known server.xml to a 60 min timeout setting, but yet we will see timeouts as soon as 10min.

Running through the standard troubleshooting now w/ BOBJ support...but any immediate ideas or thoughts would be appreciated.

KMS

[Former Member · Accepted solution]

First thing that comes to mind is that your load balancer does not enforce session affinity, which means everyime the load goes from on server to the other the session gets lost. Make sure it has sticky sessions enabled.

Caroline

[Former Member · Accepted solution]

Thanks...we will look at session affinity. Trying to collect more info on the load balancer at this time.

[BasicTek · Accepted solution]

3.1 is supposed to support serialized sessions and not need session affinity (aka persistant sessions) anymore.

Do you have the cleanup listener enabled in the web.xml? I think I heard this causes session problems in XI 3.x whereas it resolved them in XIR2.

Regards,

Tim

[former_member136842 · Accepted solution]

Hello,

i` m guessing aswell thats something with the LB.

You could check if both Clusternodes are synchronized in their time. If not configure them with an NTP Client so that they have both the identical system time.

Regards

-Seb.

[Former Member · Accepted solution]

We are still waiting for the settings on the LB (stickiness, timeout settings etc.). This is all I have as far as the characteristics of the LBu2026u201D using policy based symmetric load balancingu201D

Last night I ran testsu2026and could not reproduce timeouts when by-passing the LB (accessed BOE launching browser on web server itself using actual servername:8080 in url) . I ran workflows and random periods of absolute inactivity of 5,10,30, 50 min plus with not a single timeout. Once I accessed BOE through the https:// address thus using the LB to access the sitesu2026the timeouts came fairly consistent in the 10-15 min range of inactivity.

Will confirm time clock, my expectation is that they have this all centrally controlled. Will also check the cleanup listener.

[former_member136842 · Accepted solution]

Hello,

thats interesting !

Maybe your LB has some problems with the crypting/ de- crypting of the SSL certificates ?!

Regards

-Seb.

[Former Member · Accepted solution]

-The customer has confirmed sticky sessions are enabled. We are also trying to obtain the LB settings relevant to any sort of timeout/threshold.

-Persistence is set by source ip address by default and they insert a cookie for server identification only(not sure if this something to note or not).

-We basically find that the error only occurs in using the LB. You can have intervals of inactivity of 5,10,20,30 or 45 min without any timeout error whatsoever if you bypass the LB. The error occurs consistently in the 10-15 min window of activity using LB.

-When we get the error, a Winshark trace shows the following (I xxx'd out the server names)...

xxxxxx->xxxx

GIOP.............................!zI...........LogonWithTokenEx4..............>3&cY=10.10.70.54,8P&cZ=atdc-xxxx.xxx.xxxxxx.com,

8P......1.4.4.0.5.4.J.8.V.A.0.Y.f.g.G.F.v.Z.B.7.2.G.4.4.0.5.3.J.5.1.h.q.I.a.T.P.S.M.M.C.b.k.p.F.A.I.L.V.R..

xxxxxxx->xxxx

GIOP....\...................IDL:img.seagatesoftware.com/OCA/oca_abuse:3.2..)..............o.....O.C.A._.A.b.u.s.e. .e.x.c.e.p.t.i.o.n. .1.0.5.0.3. .a.t. .[...\.e.x.c.e.p.t.i.o.n.m.a.p.p.e.r...c.p.p. .:. .6.7.]. . .4.2.0.1.0. .{.}..........N.o.t. .a. .v.a.l.i.d. .l.o.g.o.n. .t.o.k.e.n... .(.F.W.B. .0.0.0.0.3.). .C.a.n.n.o.t. .f.i.n.d.

.t.o.k.e.n.

This error also appears at 15:44:21 during the conversation between webserverxxxxxx and appserverxxxxxx:

ImplServ/OSCAFactory/connection_failure:1.0...p.....%...S.e.s.s.i.o.n. .I.D. .i.s. .n.o.t. .v.a.l.i.d..

These errors only seem to show that some event occurred resulting in an invalid/missing token, with no insight to what that event actually was....we are analyzing the rest of the traces.

BTW, I have a "Message" in w/ BOBJ...so I am hoping we have a breakthrough soon.

Thanks again for all the ideas.

Edited by: Kevin Smolkowicz on Jan 29, 2009 3:27 AM

[BasicTek · Accepted solution]

GIOP is the protocol used between a client tool such as crystal or deski and the CMS. It could also be from launching deski or webi 3-tier.

I'm not sure what your client app was doing going through the load balancer so I'm assuming it's the 3-tier deski???

Regards,

Tim

[Former Member · Accepted solution]

I will confirm, but to my knowledge...this client does not use DeskI or WebI 3Tier. I am confirming the exact act that resulted in the error.

However, I tested on their enviornment and it was not exclusive to any sort of workflow. In this environment, if, after a period of inactivity for approx 10-15 min, you click on Report List, click Preferences, view a report...you will receive the FWM 01002 error as long as you are engaging the load balancer (https://server.bi.com).

Accessing BOE via Tomcat (http://servername:8080/InfoViewApp)...you can go 5,10,20,45 min of inactivity and the session holds perfectly no matter what the workflow is.

Our focus is currently set on the LB, but some Winshark trace files are still being reviewed. Specifically during the period of inactivity before the action that caused the error.

Just in case there are any Load Balancer folks out there...here are the global settings they have on the LB...(sticki sessions are enabled)

Server Load Balancing - global parameters

Predictor = least-conn

Force-deletion = 0

Reassign-threshold = 20

Reassign-limit = 3

TCP-age = 30

UDP-age = 5

Sticky-age = 5

TCP-syn-limit = 65535

msl = 8

TCP-total conn = 2

Unsuccessful conn = 0

NO-RESET-on-max-conn = Disabled

Ping-interval = 2

Ping-retries = 4

Session ID age = 30

[Former Member · Accepted solution]

We have a conf call on 2/5/09 with BOBJ Support (SME on session mgmt, not a front line resource) and the load balancer vendor the cust is using....I will update the thread with relevant info.

Customer believes the load balancer is likely culprit, but no trace will prove it by showing what precisely is invalidating the token/session causing BOBJ to throw up the error.

[Former Member · Accepted solution]

Update...

We have been unable to identify the smoking gun, but we made a bit of progress. Our testing was in an environment where Xcelsius models are using QaaWS data providers. The only way to generate the FWM 01002 error is initializing the Xcelsius model at anytime in the workflow.

We could go an hour plus without any timeouts...even with intervals of 10,15, 20 minutes with zero activity. The moment we initialize an Xcelsius model with QaaWS we will get the FWM 01002 error after any period of inactivity of around 10-15 min...well below the 60 min timout threshold applied to all known parameters.

So, SAP Support and our team is foccussed on the QaaWS as it seems that sessions are becoming invalidated only when they are inacted.

[Former Member · Accepted solution]

I am experiencing the very same symptom and it is also with Xceluis models. Within other workflows or interfaces, timeout and the 1002 error never appear. Thanks for the help, I hope you find a fix!!

[Former Member · Accepted solution]

We have confirmed the Load Balancer has nothing to do with the behavior. What has been causing the FWM 01002 error is a default timeout with sessions that use web services. Out of the box there is no timeout setting in the dswsbobje web.xml or dsws.properties file. It is simply 20 minutes inherently.

Follow the steps in SAP Note 1244342 and it will push the FWM 01002 error out 1 hour or whatever your setting is defined to.

We still do not believe that the session timeouts for dswsbobje are managed correctly...here is my recent follow up with Support and we are awaiting response....

-We added the timeout setting for dsws.properties per the SAP note 1244342 to just over 1 hour. However, this just pushes the behavior out 1 hour and is NOT a resolution.

-What we cannot determine is... if/how/when does the session.timeout "reset". Meaning, the user is presented with a .swf file on login. At that moment, the "clock starts" on the timeout. What action precisely resets/stops the timer from a session timeout perspective? If the user navigates to other objects in InfoView over the course of an hour that does not stop the dsws timeout clock they will get the error and have to shut down the browser and start over.

-We believe it is a defect that when the dsws timeout threshold is reached, you cannot simply log out/in within the same browser....you must close the browser and come back in. Please confirm this as by design or a defect. A better error message than FWM 01002 should be presented so the user knows it is just a timeout and to log back in.

[Former Member · Accepted solution]

We have confirmed the Load Balancer has nothing to do with the behavior. What has been causing the FWM 01002 error is a default timeout with sessions that use web services. Out of the box there is no timeout setting in the dswsbobje web.xml or dsws.properties file. It is simply 20 minutes inherently.

Follow the steps in SAP Note 1244342 and it will push the FWM 01002 error out 1 hour or whatever your setting is defined to.

We still do not believe that the session timeouts for dswsbobje are managed correctly...here is my recent follow up with Support and we are awaiting response....

-We added the timeout setting for dsws.properties per the SAP note 1244342 to just over 1 hour. However, this just pushes the behavior out 1 hour and is NOT a resolution.

-What we cannot determine is... if/how/when does the session.timeout "reset". Meaning, the user is presented with a .swf file on login. At that moment, the "clock starts" on the timeout. What action precisely resets/stops the timer from a session timeout perspective? If the user navigates to other objects in InfoView over the course of an hour that does not stop the dsws timeout clock they will get the error and have to shut down the browser and start over.

-We believe it is a defect that when the dsws timeout threshold is reached, you cannot simply log out/in within the same browser....you must close the browser and come back in. Please confirm this as by design or a defect. A better error message than FWM 01002 should be presented so the user knows it is just a timeout and to log back in.

[Former Member · Accepted solution]

Hi Kevin,

Did you get any response from BOBJ/SAP support on this issue?

We are also facing the same issue.

Thanks!

-Deepu

[denis_konovalov · Accepted solution]

One way to avoid Xcelsius dashboard timeouts when it uses QAAWS is to add a dummy QAAWS to the dashboard and made this QAAWS resfresh every 5 or 10 minutes.

Dashboard will never timeout

[Former Member · Accepted solution]

So was this issue resovled? I have the same issue on our farm. Getting this when using OpenDocument URL for QaaWS and xCelsius.

[Former Member · Accepted solution]

Hi Kevin,

Would like to know if your problem was resolved already and what was the resolution. We're having the same issue.

Thanks,

Joel

[Former Member · Accepted solution]

When this issue happens, we can not navigate back to "Document List" again, it throws session expired error when we click on "Document List". That's when we log off close the browser and start over.

Here is a simple work around when you see this error message while hitting "Document List",

Instead of clicking Document List, go to home page and click on "My Favorites" it establishes new connection with other CMS in cluster, and you will be fine from there, do not need to log off and start over.