commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Rupp <hansj.r...@googlemail.com>
Subject Re: [daemon]
Date Fri, 22 Jul 2011 08:34:57 GMT
2011/7/21 Mladen Turk <mturk@apache.org>

> On 07/21/2011 08:58 AM, Hans Rupp wrote:
>
>> 2011/7/19 Mladen Turk<mturk@apache.org>
>>
>>
>>> Well, write an ant task and start your application via ant.
>>> This is the first thing that comes to my mind.
>>> Or write you own simple class that will exec new jvm and
>>> monitor it's exit value.
>>>
>>> Thanks again, but i'm not familiar with ant and don't how to write a task
>>>
>> that can permanently monitor my application.
>>
>
> So you are out of luck then ;)
>
>
>  I think your second suggestion isn't realy a solution, what should i do if
>> the monitoring jvm crashes?
>>
>
> That's why its called "monitoring" it doesn't do any job except
> checking if the child is alive, and if not restart it according to
> some rules. People even write this kind of layer for standard services,
> because your application can become unresponsive without
> crashing the JVM. Also if you think your application could
> crash the JVM your are in much bigger problem.
>
> I think your entire use case is sort of an oxymoron.
> You wish a full blown service (like you've said "os-layer")
> and still to have the userland GUI. Split those two parts
> and use the IPC for communication between them.
>
>
> So i should have two jvm's, one running my non-gui stuff
as a windows service and one running the gui as a windows
task right?  And this two should communicate via IPC
e.g tcp/ip right?
But isn't that a lot of overhead if i can have it all running in one jvm
without IPC?
Can please explain why one shouldn't use a service with a gui ? Sorry but i
still don't understand that point.

>
>
> Regards
> --
> ^TM
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: user-unsubscribe@commons.**apache.org<user-unsubscribe@commons.apache.org>
> For additional commands, e-mail: user-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message