8:23 a.m.
On 07/13/2015 03:06 AM, Carlo de Wolf wrote:
On 06/12/2015 02:57 PM, David M. Lloyd wrote:
> This is yet another good use case for an idea I proposed at the last
> couple developer meeting: the idea of configurable "availability"
> services, where you add a configuration which says "when these
> components and/or configured services are available, perform this
> action" where the action might be to notify a load balancer, perform a
> notification to humans, or even drop a file to the filesystem (which
> would be directly useful to this use case).
>
> Note (in case someone thinks this is a great idea and runs out to
> implement it right away) that when I say "configured services" I do not
> mean MSC service names; more like management capabilities where you have
> a constrained namespace and each subsystem can contribute services to
> this category.
Wouldn't implementing a MSC service with dependencies be just the quick
fix that covers the use case? :-)
Of course; however there aren't MSC services that represent services
like entire WARs, and also, MSC service names are not API so if and when
we change service names for e.g. servlets in future versions, things
will break. The idea is to establish the function in terms of EE app,
module, and component names, and subsystem/model-specific names rather
than service names (which are really an implementation detail).
For a particular example, it's very likely that we will change the way
services are assigned to EJBs.
Carlo
>
> Also note that Java 9 adds limited support for signalling unrelated
> processes, though at the moment on UNIX the signals are basically
> limited to TERM and KILL.
>
> On 06/12/2015 07:06 AM, Jason T. Greene wrote:
>>> On Jun 10, 2015, at 11:46 AM, Brian Stansberry
>>> <brian.stansberry(a)redhat.com> wrote:
>>>
>>> So, what purpose is this fulfilling?
>>>
>>> 2) How does other software solve this problem? If it's solving a valid
>>> problem, it seems like there would be a typical solution.
>> The classic UNIX solution is that the daemon forks and returns,
>> dropping a PID file of its child to disk, after it is done
>> initializing and exits with an error code when there is a problem.
>>
>> Systemd added other approaches, where a daemon can signal systemd
>> directly, or it can use dbus to send a message.
>>
>> The former can't be done efficiently in Java because it doesn't have
>> a pure fork(), only an exec. Although it would be possible to emulate
>> with an exec with an unacceptable hit to boot time. The latter
>> options are too Linux specific.
>>
>> I think the best solution would be for us to add a signaling
>> mechanism specifically for this purpose. We could use sun.misc.Signal
>> (potentially an issue on Java 9), or we could exec the kill command
>> to signal a process.
>>
>> We could also use a specially status file (e.g standalone.sh
>> --start-status-file=blah) for a script to monitor.
>>
>> Thoughts?
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
--
- DML