>Oh, then why is it not a problem with JRun 3.1 on the same OS if it is a
>problem with the OS?
I can't explain that.
Will
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
