Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

java.lang.outofmemory - but where?

java.lang.outofmemory - but where?

java.lang.outofmemory - but where?

Were running a Silverstream 3.75 cluster on Win2k connecting to a MS-SQL7 DB.
My problem is that both servers in the cluster keep crashing with a java.lang.outofmemory error. Both our servers have at least 1gb of ram and are started with +Xmx1024 to allocate memory to the java heap.

We have checked all our code, queries etc and there is nothing obviously wrong. Our site gets around 50,000 page requests a day and I am starting to think Silverstream cannot handle this kind of traffic!

Any advice much appreciated

RE: java.lang.outofmemory - but where?

I am working with a situation that sounds similar. Did you get to solution? Help.

RE: java.lang.outofmemory - but where?

I also had this problem it is due to the fact that Silverstream does not release memory/resources, so it throw the "java.lang.outofmemory" error after some times (depending on the size and number of the applications running).
The solution I'm using is to restart periodically the SS service ... but I'm not very happy of this ...

RE: java.lang.outofmemory - but where?

We are also running 3.7.5 on W2K servers and having the same problem after running 19-20 hrs.  We are currently utilizing optimizeIt and trying to determine with Novell Support the problem.  We have also tested the same Director application on a Solaris 8 server, it's running numerous days without problems.

The more details I can get, the more information I can supply to ISV support.  We are determined to be able to deliver our customers a solution which can run on W2K servers, so we will be providing Novell OptimizeIt snapshots this week.

RE: java.lang.outofmemory - but where?


We are running 3.73 on W2K, though at a low traffic volume. We also experienced irregular behaviour - lock-ups, server bounces. Our solution, and I stress this may be of no use to you, was to have a scheduled object which rebooted the   AGServer every night. Since then no problems. Go figure.


RE: java.lang.outofmemory - but where?

Hi There,

We managed to solve the problem by doing the following:-

1. Changing all concatenated strings to Stringbuffers.
2. Applying 1570-02.jar patch from Silverstream Support.
3. Checking the server logs for 404 errors and resolving any pages which could not be found (too many of these 404s will bring a server down very quickly).

By doing all the above, my server which lasted a couple of hours now stays stable for at least a 2 weeks.


RE: java.lang.outofmemory - but where?

We also sometimes get the java.lang.OutOfMemory error in our AgErrorLog. However, when we check our own application log, we realize it is a database exception thrown when we tries to close a Statement object:

JZ006: Caught IOException: java.io.IOException: JZ0EM: End of data.

Not sure if anybody else have similar problem.  We are using jConnect 5.2 for Sybase Enterprise.

RE: java.lang.outofmemory - but where?

Hi Wilbo,

I am having the same issue regarding SilverStream 3.73 out of memory error.  I have to restart my application servers daily to avoid server crash.

In your previous posting you gave some suggestions regarding this memory issue:
1. changing all concatenated strings to StringBuffers

I have a question regarding #1.  Are you talking about append all the Strings to StringBuffers?  Please provide me with some examples.

Any help would be greatly appreciative.


RE: java.lang.outofmemory - but where?


Do you know where I can get the 1570-02.jar patch?  I talked to Novell techincal support and they said that each patch is customer specific.  I wanted to read more about this patch but I was unable to find any document on it.

Our main issue regarding memory leakage is that the application server's memory, at times with no process running, start to increase above 1 gig which in turn crash the server.  I can't pin point where or why the memory would increase even though there are no processes running on the application server.  As far as I know, we have one object that is triggered every 20 minutes and all it does it simple SQL query and update to database.  I monitored this object daily and it doesn't seem that this is the cause of memory leakage, but I am not ruling out this object yet as being the cause.

Do you have any idea why this is happening?

RE: java.lang.outofmemory - but where?

I notice it has been some time since anyone has posted in this thread. We ar still having the same problem. We have not solved it yet but I think we may be getting closer. It appears that when Silverstream is run as a service it ignores any startup paramaters. We test this by addin the +verbose:vmopts which should show the vm details in the log file. Alas no VM details appear in the log file but do appear in console.  

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close