I cannot say that I had a similar problem but see if this helps. Even I had Weblogic 5.1 running JSPs which would talk to Tuxedo and that would inturn talk to the database.
The problem that we faced was that the machine would suddenly a stop responding. The CPU usage would be 100%. We tried to trace this random problem and figured that it was because one of the queries in did not have a terminating character and hence there was a run away problem. Now coming back to your case, it could be a bug which has similar consequences. In your clustered environment, it would get executed based on the load balancing algorithm and hence it behaves in that fashion. May be that I am wrong in analysing your problem but worthwile noting that this condition is capable of leading to the behaviour u described. -Jeetendra -----Original Message----- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Ashwani Kalra Sent: Friday, November 09, 2001 12:28 PM To: [EMAIL PROTECTED] Subject: Re: OutOfMemoryError Do you require so many stateless and Entity beans. For each type of bean there will be separate pool. Are your entity beans coarse grained. Point is to try to reduce these components ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Cheers Ashwani Kalra Sr. Mem. Dev. Staff Aithent Technologies India http://www.geocities.com/ashwani_kalra/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Vikas Dwivedi Sent: Friday, November 09, 2001 11:00 AM To: [EMAIL PROTECTED] Subject: Re: OutOfMemoryError Hi, Another thing to look into may be, the number of beans set to be created into the pool at startup/ number of beans in free pool. If this number is high it can be a memory hogger. This needs to be set seperately for each bean depending on its functionality. Vikas. Valerio Gentile wrote: > Hi everybody. > > My team deployed 72 EJBs (36 entity and 36 session stateless) in a Weblogic 5.1 instance on a cluster of 5-6 nodes (I'm not sure). Everything worked fine. A few days after that (when the instance has been restarted nearly once a day due to other reasons), an instance has given an OutOfMemoryError (without any stack trace) in the middle of the night, and the operators had to restart that instance. The same thing has happened (and is happening 'til now) nearly once a day on different instances of the cluster, in a absolutely randomic way. > > I forgot two big things: > 1) noone was using the EJB application at the moment of the error, and we had probably 2-3 users (we're in a users' fillin'-in activity, and we had holidays) during these days; > 2) we have other apps running on the same cluster instances. > > Due to the fact we have no log but this OutOfMemoryError (and no monitor tools), we can't say it's EJB's fault, but the problem started after the cluster deploy. > > The instance has 128 Mb maximum heap size, and JDK 1.2.2 > > My question is: has anybody had a similar problem? Does anybody know something about it? I would appreciate so much every suggestion. > > Thank's a lot > Valerio Gentile > > =========================================================================== > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
