Portal Errors SSO server response not populated

 5 Replies
 0 Subscribed to this topic
 14 Subscribed to this forum
Sort:
Author
Messages
Mick
Veteran Member Send Private Message
Posts: 82
Veteran Member
Hello,
On an intermittent bases and nothing too consistent on the form name..........
GL165, IC's, PO'.s

The users will report 'freezing' then this message pops up

SSO server response not populated
details.
/servlet/Router/Transaction/Erp
SSORequest() - sso.js 
 
I have been running xscrgen and have run scrgen to the product line but still.  It goes quiet for a while ,then shows again (no system changes)
We are on LCT9.0.1.8/msp6 - Unix aix 6.1.
I understand a bit behind here, but is there anything I can look at to try and resolve.
I hear this has been going on a couple of years.
I also hear things like..... oh it is the portal book marks, oh it is the batch jobs.  
But can you or anyone shed some light? 
Thank you


 
Jimmy Chiu
Veteran Member Send Private Message
Posts: 641
Veteran Member
One of my remote site gets that error alot due to network latency.
Mick
Veteran Member Send Private Message
Posts: 82
Veteran Member
Any thing I can check or have checked?
When it is happening?
anything?
Kwane McNeal
Veteran Member Send Private Message
Posts: 479
Veteran Member
If Jimmy is right, you can do some of the following:
1) From the PC the user is using, ping back to the LSF server. Keep in mind that you'll need a larger buffer size to more closely simulate a typical TCP payload, since ping is using a small (I think 32-byte) ICMP payload by default
2) Check the network switch for dropped packets in all of the following that apply: LSF Server switch port, Database Server switch port, client location border router (if physically connected via anything other than direct LAN access), client PC (again, if physically connected via anything other than direct LAN back to the LSF server)

Now if NONE of that is it, start using tmmon to see if anything odd is happening to the program behind the scenes. You're looking for stuff like programs waiting, or tons of client threads from the same PIDs (aka WebSphere threads). If that's the case, then you'll have to look a bit deeper, since you could have some sort of a performance bottleneck.

Call me if you need me, and if I can help in anyway.

Kwane
Jimmy Chiu
Veteran Member Send Private Message
Posts: 641
Veteran Member
This is what happens usually on my remote site(s).

The users on remote site would call me. For example, they would try to submit a jobs, approve a req etc and they would get an hourglass then the sso.js error.

When I check the jobschd or the req, they are submitted/completed/approved at the server side.

Seems to me that the server "respond" back to the user took too long/timeout due to lost packet or whatever.



Kwane McNeal
Veteran Member Send Private Message
Posts: 479
Veteran Member
To clarify my post in relation to Jimmy's findings, I concur. While I have seen other reasons for this, if there is a remote site involved, it is almost always a latency issue first, and some other issue second.
This plagued me so much so at a number of retail clients, I modified a custom written load test tool to isolate this very set of issues.

Kwane