Menu
▾
▴
wrapper-user
|
From: Marcin W. <mwa...@su...> - 2007-10-09 15:37:29
|
Hello. In documentation we can read: "The Wrapper works with this kind of application by starting up the application, as in the first method, using the "start" class and then calling the main method of the "stop" class when it is time for the application to be shutdown.". I have noticed that calling "stop" class is done within the same JVM as calling "stop" class. Is it possible to configure wrapper to call "stop" class in another JVM? Regards, Marcin |
|
From: Marcin W. <mwa...@su...> - 2007-10-09 15:37:29
|
One correction: Should be: I have noticed that calling "stop" class is done within the same JVM as calling *start* class. Marcin Waldowski wrote: > Hello. > > In documentation we can read: > "The Wrapper works with this kind of application by starting up the > application, as in the first method, using the "start" class and then > calling the main method of the "stop" class when it is time for the > application to be shutdown.". > > I have noticed that calling "stop" class is done within the same JVM > as calling "stop" class. Is it possible to configure wrapper to call > "stop" class in another JVM? > > Regards, Marcin > |
|
From: Leif M. <le...@ta...> - 2007-10-16 15:54:10
|
Marcin, Not currently. The Wrapper is only capable of monitoring a single JVM at the moment. In addition to be very heavy, controlling the lifecycle and all of the possible failure modes for a second JVM would get complicated in a hurry. What is the problem you are encountering that is requiring this? I may have some ideas for you. Cheers, Leif Marcin Waldowski wrote: > One correction: > > Should be: I have noticed that calling "stop" class is done within the > same JVM as calling *start* class. > > Marcin Waldowski wrote: > >> Hello. >> >> In documentation we can read: >> "The Wrapper works with this kind of application by starting up the >> application, as in the first method, using the "start" class and then >> calling the main method of the "stop" class when it is time for the >> application to be shutdown.". >> >> I have noticed that calling "stop" class is done within the same JVM >> as calling "stop" class. Is it possible to configure wrapper to call >> "stop" class in another JVM? >> >> Regards, Marcin >> |
|
From: Marcin W. <mwa...@su...> - 2007-10-22 07:58:43
|
Hello. My problem is related to itegrate Apache Geronimo 2.0.1 and JWS via second integration method. The same problem was touched is following thread http://www.mail-archive.com/us...@ge.../msg07665.html Calling "stop" class within the same JVM as calling *start* class results with error in Geronimo. As David Jencks wrote it's intended to run shutdown.jar (from JWS point of view - "stop" class) in a different vm. The workaround is to use first integration method. However it need to increase wrapper.jvm_exit.timeout because Geronimo shutdown hook may need some more time to complete (the time depend on what is deployed on Geronimo). So it could be better to stay with second integration method. Do you have some idea what to do to use second integration in such situations? Regards, Marcin Leif Mortenson wrote: > Marcin, > Not currently. The Wrapper is only capable of monitoring a single JVM at > the moment. In addition to be very heavy, controlling the lifecycle and > all of the possible failure modes for a second JVM would get complicated > in a hurry. > > What is the problem you are encountering that is requiring this? > I may have some ideas for you. > > Cheers, > Leif > > Marcin Waldowski wrote: >> One correction: >> >> Should be: I have noticed that calling "stop" class is done within the >> same JVM as calling *start* class. >> >> Marcin Waldowski wrote: >> >>> Hello. >>> >>> In documentation we can read: >>> "The Wrapper works with this kind of application by starting up the >>> application, as in the first method, using the "start" class and then >>> calling the main method of the "stop" class when it is time for the >>> application to be shutdown.". >>> >>> I have noticed that calling "stop" class is done within the same JVM >>> as calling "stop" class. Is it possible to configure wrapper to call >>> "stop" class in another JVM? >>> >>> Regards, Marcin >>> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > |
|
From: Leif M. <le...@ta...> - 2007-10-22 11:44:57
|
Marcin, Without using the wrapper, many applications launch a second JVM instance simply to trigger the shutdown of the first. This is usually done by deleting an anchor file or sending a command via a socket. The wrapper makes this much lighter by running this shutdown code in the same JVM. Are you having problems running the shudown class in the same JVM? Or just assuming that it will not work. Shutdown classes tend to be quite simple in most cases. Cheers, Leif Marcin Waldowski wrote: > Hello. > > My problem is related to itegrate Apache Geronimo 2.0.1 and JWS via > second integration method. > > The same problem was touched is following thread > http://www.mail-archive.com/us...@ge.../msg07665.html > > Calling "stop" class within the same JVM as calling *start* class > results with error in Geronimo. As David Jencks wrote it's intended to > run shutdown.jar (from JWS point of view - "stop" class) in a different vm. > > The workaround is to use first integration method. However it need to > increase wrapper.jvm_exit.timeout because Geronimo shutdown hook may > need some more time to complete (the time depend on what is deployed on > Geronimo). So it could be better to stay with second integration method. > > Do you have some idea what to do to use second integration in such > situations? > > Regards, Marcin > > Leif Mortenson wrote: > >> Marcin, >> Not currently. The Wrapper is only capable of monitoring a single JVM at >> the moment. In addition to be very heavy, controlling the lifecycle and >> all of the possible failure modes for a second JVM would get complicated >> in a hurry. >> >> What is the problem you are encountering that is requiring this? >> I may have some ideas for you. >> >> Cheers, >> Leif >> >> Marcin Waldowski wrote: >> >>> One correction: >>> >>> Should be: I have noticed that calling "stop" class is done within the >>> same JVM as calling *start* class. >>> >>> Marcin Waldowski wrote: >>> >>> >>>> Hello. >>>> >>>> In documentation we can read: >>>> "The Wrapper works with this kind of application by starting up the >>>> application, as in the first method, using the "start" class and then >>>> calling the main method of the "stop" class when it is time for the >>>> application to be shutdown.". >>>> >>>> I have noticed that calling "stop" class is done within the same JVM >>>> as calling "stop" class. Is it possible to configure wrapper to call >>>> "stop" class in another JVM? >>>> >>>> Regards, Marcin >>>> |
|
From: Marcin W. <mwa...@su...> - 2007-10-22 12:33:31
|
Leif Mortenson wrote:
> Marcin,
> Without using the wrapper, many applications launch a second JVM
> instance simply to trigger the shutdown of the first. This is usually
> done by deleting an anchor file or sending a command via a socket.
> The wrapper makes this much lighter by running this shutdown
> code in the same JVM.
Yes, and this is OK! :)
>
> Are you having problems running the shudown class in the same
> JVM?
Yes, in case of Geronimo it result with IllegalStateException.
In "start" class we have execution of:
KernelRegistry.registerKernel("MainBootstrapper");
and in "stop" class we have execution of the same:
KernelRegistry.registerKernel("MainBootstrapper");
which in "stop" class result with
java.lang.IllegalStateException: A kernel is already running this
kernel
You can see discusion about it here:
http://www.mail-archive.com/us...@ge.../msg07665.html
Result of discussion is that it is *intended* to run shutdown class in a
different vm. It means that second integration method can not be used
(only first can be used) for Geronimo.
Of course the best solution is to modify Geronimo shutdown class. But
first I decided to ask You if it is posible to do some trick to make it
works in second integration method ;)
I'm *not* trying to tell you that it's worth to implement calling "stop"
class in different vm in JSW. Definitely I think that this is *not*
worth for this single case :) I'm just asking for some trick which meybe
is implemented already ;)
Regards, Marcin
|
|
From: Leif M. <le...@ta...> - 2007-10-30 00:40:04
|
Marcin,
Sorry, the Wrapper does not do anything fancy with class loaders or
anything else as that would have consequences for other applications.
It looks like Geronimo is not going to work as is. It should be very
easy to modify it so it would work with either method 1 or method 2
smoothly. Some applications even go as far as to support method 3
directly.
Cheers,
Leif
Marcin Waldowski wrote:
> Leif Mortenson wrote:
>
>> Marcin,
>> Without using the wrapper, many applications launch a second JVM
>> instance simply to trigger the shutdown of the first. This is usually
>> done by deleting an anchor file or sending a command via a socket.
>> The wrapper makes this much lighter by running this shutdown
>> code in the same JVM.
>>
>
> Yes, and this is OK! :)
>
>
>> Are you having problems running the shudown class in the same
>> JVM?
>>
>
> Yes, in case of Geronimo it result with IllegalStateException.
>
> In "start" class we have execution of:
> KernelRegistry.registerKernel("MainBootstrapper");
> and in "stop" class we have execution of the same:
> KernelRegistry.registerKernel("MainBootstrapper");
> which in "stop" class result with
> java.lang.IllegalStateException: A kernel is already running this
> kernel
>
> You can see discusion about it here:
> http://www.mail-archive.com/us...@ge.../msg07665.html
> Result of discussion is that it is *intended* to run shutdown class in a
> different vm. It means that second integration method can not be used
> (only first can be used) for Geronimo.
>
> Of course the best solution is to modify Geronimo shutdown class. But
> first I decided to ask You if it is posible to do some trick to make it
> works in second integration method ;)
>
> I'm *not* trying to tell you that it's worth to implement calling "stop"
> class in different vm in JSW. Definitely I think that this is *not*
> worth for this single case :) I'm just asking for some trick which meybe
> is implemented already ;)
>
> Regards, Marcin
|
|
From: Marcin W. <mwa...@su...> - 2007-11-02 11:30:34
|
Thanks for your answer :) Regards, Marcin Leif Mortenson wrote: > Marcin, > Sorry, the Wrapper does not do anything fancy with class loaders or > anything else as that would have consequences for other applications. > It looks like Geronimo is not going to work as is. It should be very > easy to modify it so it would work with either method 1 or method 2 > smoothly. Some applications even go as far as to support method 3 > directly. > > Cheers, > Leif > |
|
From: Marcin W. <mwa...@su...> - 2007-10-19 08:42:31
|
Hello. Had anyone similar problem? Regards, Marcin Marcin Waldowski wrote: > One correction: > > Should be: I have noticed that calling "stop" class is done within the > same JVM as calling *start* class. > > Marcin Waldowski wrote: >> Hello. >> >> In documentation we can read: >> "The Wrapper works with this kind of application by starting up the >> application, as in the first method, using the "start" class and then >> calling the main method of the "stop" class when it is time for the >> application to be shutdown.". >> >> I have noticed that calling "stop" class is done within the same JVM >> as calling "stop" class. Is it possible to configure wrapper to call >> "stop" class in another JVM? >> >> Regards, Marcin >> > > |
|
From: Leif M. <le...@ta...> - 2007-10-19 16:28:23
|
Marcin, Answered you on the 17th: --- Marcin, Not currently. The Wrapper is only capable of monitoring a single JVM at the moment. In addition to be very heavy, controlling the lifecycle and all of the possible failure modes for a second JVM would get complicated in a hurry. What is the problem you are encountering that is requiring this? I may have some ideas for you. Cheers, Leif Marcin Waldowski wrote: > Hello. > > Had anyone similar problem? > > Regards, Marcin > > Marcin Waldowski wrote: > >> One correction: >> >> Should be: I have noticed that calling "stop" class is done within the >> same JVM as calling *start* class. >> >> Marcin Waldowski wrote: >> >>> Hello. >>> >>> In documentation we can read: >>> "The Wrapper works with this kind of application by starting up the >>> application, as in the first method, using the "start" class and then >>> calling the main method of the "stop" class when it is time for the >>> application to be shutdown.". >>> >>> I have noticed that calling "stop" class is done within the same JVM >>> as calling "stop" class. Is it possible to configure wrapper to call >>> "stop" class in another JVM? >>> >>> Regards, Marcin >>> |
|
From: Hubert F. <Hub...@ab...> - 2007-10-22 08:05:46
|
Hi, IllegalStateException while stopping Wrapper? Sounds familiar somehow. Maybe it has something to do with this? http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1799489&group_= id=3D39428&atid=3D425187 The solution worked for me. No more IllegalStateException on shutdown. hub >>> Marcin Waldowski <mwa...@su...> 22.10.2007 09:58 >>> Hello. My problem is related to itegrate Apache Geronimo 2.0.1 and JWS via=20 second integration method. The same problem was touched is following thread=20 http://www.mail-archive.com/us...@ge.../msg07665.html=20 Calling "stop" class within the same JVM as calling *start* class=20 results with error in Geronimo. As David Jencks wrote it's intended to=20 run shutdown.jar (from JWS point of view - "stop" class) in a different = vm. The workaround is to use first integration method. However it need to=20 increase wrapper.jvm_exit.timeout because Geronimo shutdown hook may=20 need some more time to complete (the time depend on what is deployed on=20 Geronimo). So it could be better to stay with second integration method. Do you have some idea what to do to use second integration in such=20 situations? Regards, Marcin Leif Mortenson wrote: > Marcin, > Not currently. The Wrapper is only capable of monitoring a single JVM = at > the moment. In addition to be very heavy, controlling the lifecycle = and > all of the possible failure modes for a second JVM would get complicated > in a hurry. >=20 > What is the problem you are encountering that is requiring this? > I may have some ideas for you. >=20 > Cheers, > Leif >=20 > Marcin Waldowski wrote: >> One correction: >> >> Should be: I have noticed that calling "stop" class is done within = the=20 >> same JVM as calling *start* class. >> >> Marcin Waldowski wrote: >> =20 >>> Hello. >>> >>> In documentation we can read: >>> "The Wrapper works with this kind of application by starting up the=20 >>> application, as in the first method, using the "start" class and = then=20 >>> calling the main method of the "stop" class when it is time for the=20 >>> application to be shutdown.". >>> >>> I have noticed that calling "stop" class is done within the same = JVM=20 >>> as calling "stop" class. Is it possible to configure wrapper to = call=20 >>> "stop" class in another JVM? >>> >>> Regards, Marcin >>> =20 >=20 >=20 > -------------------------------------------------------------------------= > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/=20 > _______________________________________________ > Wrapper-user mailing list > Wra...@li...=20 > https://lists.sourceforge.net/lists/listinfo/wrapper-user=20 >=20 >=20 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/=20 _______________________________________________ Wrapper-user mailing list Wra...@li...=20 https://lists.sourceforge.net/lists/listinfo/wrapper-user |
|
From: Marcin W. <mwa...@su...> - 2007-10-23 14:04:11
|
Hubert, This in not related to my issue, but thanks for your response :) Meybe it will help me in the future. Regards, Marcin Hubert Felber wrote: > Hi, > > IllegalStateException while stopping Wrapper? Sounds familiar somehow. > > Maybe it has something to do with this? > http://sourceforge.net/tracker/index.php?func=detail&aid=1799489&group_id=39428&atid=425187 > > The solution worked for me. No more IllegalStateException on shutdown. > hub > |
