Websphere 6.0 issues.

m@dm@x

m@dm@x

Well Known Member
All,
We recently installed TR 8.96 H1 and Webshpere 6.0 in our production environment. Over the last two weeks I've had two instances where the users cannot use the production site do to a lack of responsiveness from the web server. The proc stays at 25% for java.exe for that environment. All other environments on that server work just fine. I've had to restart the server instead of just restarting the service, it won't stop completely. I'm just wondering if anyone here has had similar issues. I've opened up a ticket with Oracle but as we all know, they are not much help.

Thanks in Advance.
 
Well, Oracle want's had me set the initial heap size to 64 and the max to 1024. I'll reboot tonight and let you know what happens.
 
Hi,

Have you installed all the fixpacks and patches as stated
by JDE MTR to all three components : WAS, IHS and Plg?
 
Yes, I've installed all of those. Oracle suggested I change the heap size and restart the service. We'll see if that helps.
 
Hi,

I also have a ticket open with GSS reference what appears to be memory issues with 8.96_H1 now and initially 8.96_H1.

Initially they thought it was a JDBC driver issue, but we proved that we are on the correct level.

We were getting slow down in the web server till it became unusable also, and the only way to cure it was to restart the web server.

After some investigations we were also told to increase our heap size memory settings to 1280.

This has improved things BUT the underlying cause of the problem is still there.

Please review your jderoot log and look for the string "No F983051 record fetched for version". This is the indication that we see that the system is starting to go wrong. When our heap memory was set at 512 we also got a java.lang.OutOfMemoryError.

The No F983051 error message tells you taht an application / report is missing the version that it cannot find. If you check the F983051 table sure enough it is missing, but this is just a red herring, and if you believe the messages then you go off and create a new version and deploy, and lo and behold it now errors on another versiom. Do not chase this erroneous paper trail.

Increasing the heap to 1280 has reduced the number of these errors appearing and stop the java.lang.outofmemory errors.

I believe that there is a major memory leak issue within the 8.96 tools release on the web.

The problem is manifesting itself in the no F983051 errors. I have a theory as to what is going on to produce these errors, but cannot conclusively prove it as of yet.

My theory is the following, the system works OK for a while, the system gets to the point where it is operating at or near near maximum heap size, something happens then that causes a memory leak.

Immediately prior to the leak a user runs application XX version YY, the memory leak happens as another user runs application ZZ version AA. The system gets confused and instead of looking for application ZZ version AA calls for Application ZZ version YY. In other words it calls the correct application, but the version from the previous application.

This is OK if your versions are all ZJDE0001 but if you have mixtures of custom versions (and who does not) then you are scuppered.

PLEASE Review your jderoot log and let me know if we have the same symptoms in the log.

The customer is on E811.SP1 / TR 8.96.D1 / Oracle OAS 10g / Oracle Database 10g R2.

We also have another customer on E811 / TR 8.98.F1 / Oracle OAS 10g / MSSQL Server / SQL 2005 JDBC drivers with the same issue.
 
Thanks for your Post Terry and I'm sorry I haven't gotten back to you. I've been sick the last few days. I just sent a PM about the issue but ignore it. I'll investigate this further and check back. I'll look through all the logs and see if I find something similar.
 
Well, wouldn't you know it, the same thing appears to happen here. I have a ticket open with Oracle and I'll show them this in the logs. I'm not sure it will help much though. Since we are not a 24/7 shop I probably set the Jas servers to restart everynight at 11:00 PM.
 
Back
Top