Java Languages Peoplesoft PeopleTools Tuning Weblogic

Weblogic Java VM Memory Parameters

When increasing the Java VM memory parameters for a PeopleSoft system under Weblogic (either in setEnv.cmd or manually by editing the cmdline registry entry if that’s your “thing”), be very careful not to increase the -XX:MaxPermSize memory allocation too much.

In fact I would leave it at 128MB or perhaps 256MB. Whatever you do, don’t update all three parameters in step, especially on a 32-bit Java, as you will hit Out of Memory errors on Weblogic startup way earlier than you expect. The MaxPermSize memory is allocated outside of the heap so the total memory you potentially need is more than you expect.

High Availability Peoplesoft PeopleTools Weblogic

Load Balancing <> High Availability <> Seamless Failover

Having a load balancer and multiple Peoplesoft VM’s at the Web and App layer with a clustered database server does not guarantee “seamless failover” for the end user – it all depends how it is all configured.

Here’s a nice example:

  • Load Balancers (x2 actually)
  • Multiple Weblogic servers
  • Multiple Application servers
  • Clustered DB server

The load balancer feeds the Weblogic servers with sessions and maintains “session stickiness” via a cookie. They in turn each know about the application servers so they can load balance across them too. All good? Nope.

Hmmm … the Weblogic servers are single server domains. With different session cookie names.

So, if a Weblogic server fails the load balancer will re-direct the session to another one. But that server is not even looking for the same session cookie name. End result for the users … the PeopleSoft login page.

But even if all the Weblogic servers did share the cookie name we have another problem – there is no session replication between the Weblogic servers as they were configured as single server domains. No Coherence, no wl_sessions table in a DB somewhere – nothing. End result for the users … the PeopleSoft login page.