Randy:
Have you thought of figuring out a way to use a separate VM for your application? Not
knowing your application, not sure that is feasible. Would be prudent to separate your
app's VM dependence from JRun's for the reason you just mentioned.
--MH
*********** REPLY SEPARATOR ***********
On 8/28/00 at 10:18 AM Scott Stirling wrote:
>What's the actual impact in a real world situation? I am (still) just
>looking for some practical example(s), not academic "shoulds." It will only
>help me when I take this to the engineer who's going to have to fix it if I
>can show him at least one reason why this is a real problem.
>
>Scott Stirling
>Allaire Corporation
>http://www.allaire.com/developer/jrunreferencedesk/
>
>> -----Original Message-----
>> From: Paul Fink [mailto:[EMAIL PROTECTED]]
>> Sent: Monday, August 28, 2000 10:02 AM
>> To: [EMAIL PROTECTED]
>> Subject: Re: Another Example of the problem with JRun3.0
>> exit() behavior
>>
>>
>> Scott,
>> Java methods should never call "exit()" except in the
>> controlling thread,
>> i.e. the main.
>> This is a good design pattern for single threaded C programs
>> and a necessity
>> for multi-threaded
>> Java programs. Method are suppose to throw exceptions that
>> can be caught and
>> handle in the
>> "proper" manner. You could ask "What other threads may be
>> running and how do
>> they want to
>> deal with the error?" After what is the point of making the server
>> embeddable?
>>
>>
>> This is Java 101 stuff and it should be a "oh $#!+" and fixed
>> with out any
>> discussion.
>>
>> ----- Original Message -----
>> From: "Scott Stirling" <[EMAIL PROTECTED]>
>> To: <[EMAIL PROTECTED]>
>> Sent: Friday, August 25, 2000 3:26 PM
>> Subject: RE: Another Example of the problem with JRun3.0
>> exit() behavior
>>
>>
>> > I'm willing to log this as a bug. But can you tell me why this is a
>> problem
>> > that can't be worked around by other means? Seriously, I think your
>> request
>> > is reasonable, but on the other hand it'd help to have a
>> good reason why
>> > you'd want to stop an embedded instance of JRun without
>> exiting the JVM.
>> >
>> > Scott Stirling
>> > Allaire Corporation
>> > http://www.allaire.com/developer/jrunreferencedesk/
>> >
>> > > -----Original Message-----
>> > > From: Hammon, Randy [mailto:[EMAIL PROTECTED]]
>> > > Sent: Friday, August 25, 2000 2:37 PM
>> > > To: '[EMAIL PROTECTED]'
>> > > Subject: Another Example of the problem with JRun3.0
>> exit() behavior
>> > >
>> > >
>> > > Last month I discovered a very uncool behavior of JRun3.0, in
>> > > which it calls
>> > > exit() when
>> > > it stops. This is a huge problem for OEMS trying to
>> embedding JRun3.0.
>> > >
>> > > I just ran into another example of why it's a bad idea for
>> > > JRun3.0 to call
>> > > exit().
>> > >
>> > > An internal customer had accidently started an instance
>> of JRun, then
>> > > proceeded to
>> > > boot our application which internally starts JRun. After
>> taking a few
>> > > minutes to boot,
>> > > our app started JRun, JRun found it's listening ports were
>> > > being used, then
>> > > it called
>> > > exit and brought down OUR app along with it. Ouch!
>> > >
>> > > Allaire. Please fix this in the next release.
>> > >
>> > > Thanks,
>> > > -Randy Hammon
>> > > Evolve Software, Inc
>> > > 1400 65th St. Suite 100
>> > > Emeryville, CA 94608
>------------------------------------------------------------------------------
>Archives: http://www.egroups.com/group/jrun-interest/
>Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/jrun_talk
>or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the
>body.
------------------------------------------------------------------------------
Archives: http://www.egroups.com/group/jrun-interest/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebarRsts&bodyRsts/jrun_talk
or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the
body.
