Go to previous topic
Go to next topic
Last Post 10/30/2013 3:40 PM by  Kwane McNeal
Portal Errors SSO server response not populated
 5 Replies
Author Messages
Mick
Private
Private
Veteran Member
(192 points)
Veteran Member
Posts:82


Send Message:

--
10/22/2013 11:47 AM
    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
    System Analyst
    Federal Government
    Veteran Member
    (1880 points)
    Veteran Member
    Posts:640


    Send Message:

    --
    10/30/2013 1:19 PM
    One of my remote site gets that error alot due to network latency.
    Mick
    Private
    Private
    Veteran Member
    (192 points)
    Veteran Member
    Posts:82


    Send Message:

    --
    10/30/2013 1:33 PM
    Any thing I can check or have checked?
    When it is happening?
    anything?
    Kwane McNeal
    President
    Private
    Veteran Member
    (1431 points)
    Veteran Member
    Posts:477


    Send Message:

    --
    10/30/2013 2:00 PM
    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
    System Analyst
    Federal Government
    Veteran Member
    (1880 points)
    Veteran Member
    Posts:640


    Send Message:

    --
    10/30/2013 3:14 PM
    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
    President
    Private
    Veteran Member
    (1431 points)
    Veteran Member
    Posts:477


    Send Message:

    --
    10/30/2013 3:40 PM
    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


    ---