Yep Sun e420.
-----Original Message-----
From: Jackie Comeau [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 09, 2001 2:39 PM
To: JRun-Talk
Subject: RE: JRun 3.0 stops responding during heavy load
Was your OS Solaris as well?
Haven't run into this problem yet, but don't have that much of load since
we run small, internal applications. But as we add more, may run into this.
Hopefully, I'll have my new server by then with JRun 3.1.
Oh, then why is it not a problem with JRun 3.1 on the same OS if it is a
problem with the OS?
Jackie
On Thursday, August 09, 2001 10:48 AM, Will Berger
[SMTP:[EMAIL PROTECTED]] wrote:
> I have run into something similar with Weblogic and the problem was not
with
> the app server, but the OS was configured to handle max of 128 file
> descriptors. We bumped it up to 1024 and things improved signficantly.
>
> Just a thought.
>
> Will
>
> -----Original Message-----
> From: Johansen, Roar [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 09, 2001 4:27 AM
> To: JRun-Talk
> Subject: JRun 3.0 stops responding during heavy load
>
>
> Our production site stops responding from time to time. It runs JRun
3.02a
> on Solaris 2.7 and Sun JDK 1.3, and behind a NES (Netscape-Enterprise/3.6
> SP3) server. When the stops occur, it has to be restarted manually. Whe
> think we have found a reason, so we want to run this by someone other
than
> ourselves, to get the theory confirmed (or rejected, for that matter ;-)
)
>
> We downloaded JRun 3.1 and have done some testing on the two platforms,
by
> making a servlet that does a sleep for 30 seconds, to be able to build a
> queue of requests to the server, and monitoring the number of open
sockets
> from the NES connector.
>
> JRun 3.1 survives this brilliantly even though I continue to issue new
> requests long after max threads has been reached (100 - i.e. 200 sockets
-
> one in and one out per thread). After a while, the queue unwinds, the
number
> of open sockets goes down, and the server continues to service requests.
>
> JRun 3.0 on the other hand, behaves oddly. Upon reaching 100 threads, it
has
> 202 open sockets (not 200!), and when the first "sleep 30" expires (and
more
> requests are queued), the number of sockets increments by two, leaving
204
> open sockets. After this, the server is dead and has to be restarted. In
due
> time, all "sleep 30"'s expire, but the number of sockets remains 204. My
> guess (and I emphasize *guess*) is that there is a timing glitch in 3.0,
> where a new socket is opened before the "old" one is closed, causing som
> kind of deadlock - and that this has been fixed somehow in 3.1.
>
> Can anyone confirm this behavior? Is it a known issue?
> Bottom line: Should we migrate to 3.1, or should we continue to
scrutinize
> the application?
>
> regards,
> Roar
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
