ibm-mobilefirstworklight-serverwebsphere-liberty

Instability on Worklight Server


I'm using websphere liberty profile v8.5.5.0 and worklight 6.2.

The full version of my WL and runtime is:

Server version: 6.2.0.00.20140922-2259
Project WAR version: 6.2.0.00.20140922-2259

I've noticed that sometimes I have troubles getting into the worklightconsole, the server takes a too big of a time to answer and most of the time it just gives me a time out.

Regarding JVM Heap its at 60 - 70% of the total heap, most likkely 1,5 Gb or something like that.

On the FFDC, sometimes I get a error saying something close to an

FFDC Incident has been created: "javax.naming.ServiceUnavailableException: ldap.example.com:389; socket closed; remaining name 'o=example' com.ibm.ws.wim.adapter.ldap.LdapConnection 1670" at ffdc.log

I have my LDAP connected to this websphere via VPN, and I know that webspheres historically have trouble dealing with LDAP.

However I don't see any more errors on the logs; the machine eventually recovers and is able to work correctly, but for some time is 'down'.

If I enable tracing, the verbosity overwhelms the machine and I can't even start the worklightconsole, neither continue to work with worklight like calling an adapter from an application.

There is one more thing, it seems that this happens more frequently after updates on existing application versions or adapters. Does this ring a bell with anyone?

If i ask for a restart when the machine is sluggish, the stoping of the websphere takes quite some time but eventually stops normally and when I start it, everything is fine right out of the bat.

Before asking for a PMR, I would like to know if there is something else I could do to troubleshoot this problem.

Thanks in advance.


Solution

  • My initial "smell" of the problem is that sometimes your VPN connection with LDAP is very slow or your LDAP server is taking too long to respond.

    My suggestion is that you try using WAIT(wait.ibm.com), it's a non-invasive easy to use diagnostic tool, to further investigate. If you find out the call to LDAP is getting hang then I suggest you try tuning Liberty LDAP cache, this should help.