Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / Tools / April 2005

Tip: Looking for answers? Try searching our database.

Out of Memory Error -- WebSphere Application Server 4.x

Thread view: 
Danda - 21 Apr 2005 17:36 GMT
Hi
We are using WebSphere Application server on Sun solaris box as a
development application server. As a part of the development, we
frequently FTP the java class files to the application server. When we
do this, we noticed that the sessions of the users who are already
logged in the application running on that WAS are getting lost. They
have to reenter the credentials again to navigate through the
application. As the day work goes on, after certain number of class
files are uploaded onto the server by FTP, the application server is
throwing Out of Memory error and coming to a halt. When we try to
access the url it throws the OutOfMemory error in the logs. This is
hampering our development work, as we have to restart the development
server atleast twice in a day. Our assumption is that, whenever we do
a class fild upload all the sesssions on the server are getting lost
and new objects/ sessions are created. Before the garbage collector
runs, the frequent upload of class files are causing to create more
and more objects. Please suggest or advise a workaround or solution
for this.

Regards
Danda
Robert Klemme - 25 Apr 2005 18:20 GMT
> Hi
> We are using WebSphere Application server on Sun solaris box as a
[quoted text clipped - 14 lines]
> and more objects. Please suggest or advise a workaround or solution
> for this.

There might be issues with old class versions that cannot be GC'ed because
objects in sessions still refer them.  Several things come to mind:

- increase mem of the VM

- don't put so much data in sessions

- decrease the lifetime of a session so it gets destroyed faster

- make sure, your app doesn't leak - it could well be a completely
unlrelated issue.  Do you get the error even if you don't upload new classes
after testing some while?

Regards

   robert
Danda - 27 Apr 2005 07:59 GMT
> > Hi
> > We are using WebSphere Application server on Sun solaris box as a
[quoted text clipped - 31 lines]
>
>     robert

Hi Robert..

Hi Robert

    Thanks a lot for Your quick reply. The problem goes liek this. We
have the development server in a different place and we do a normal
FTP of class files to the development box after modification. We
observed that while other users are logged in through the web
application GUI, we do a normal class file upload onto the application
server. So, the users' sessions are getting lost and teh application
is throwing the login screen for them. And if we do some certain no of
class file uploads to the applicatino server as the users are logged
in, the GUI is becoming not accessible as the server throws the Out Of
Memory Error in the logs and Error 500 or blank screen for the
users.We cant question on server configuration bcoz it used to run
fine. And also there is not much data kept in the sessions. We are
using Web Sphere Application server 4.x. Mean while I would like to
confirm whether 4.x supports dymanic deployment and hot deployment.

Thanks
Danda


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.