[wildfly-dev] WildFly status listener
Stuart Douglas
stuart.w.douglas at gmail.com
Wed Dec 14 17:21:40 EST 2016
In that case you should probably move the rest call out of the service
start, and have it processed by a separate thread.
Its probably not great having server start dependent on an external service
being up anyway.
Stuart
On Thu, Dec 15, 2016 at 7:10 AM, Gytis Trikleris <gtrikler at redhat.com>
wrote:
> Yes it does get processed. But because at the moment call is made from
> service's start method, the service isn't started until the request is
> processed. As a result Arquillian test fails because app server doesn't
> start fast enough.
>
>
>
> On 14/12/2016 20:49, Brian Stansberry wrote:
>
>> OK. I should probably shut up and defer to Stuart anyway. :)
>>
>> I say that because looking at his commit you linked, it looks like what
>> it does is it starts queuing up requests during boot and then when it gets
>> the ControlledProcessStateService RUNNING notification it opens the gate
>> and the queued requests get handled (as do new ones of course.)
>>
>> So that means you shouldn’t have a problematic race if you also use the
>> ControlledProcessStateService RUNNING notification. Your request will
>> either get there before the gate opens and be queued momentarily before
>> being processed, or it will get there after the gate opens and be
>> processed. Either way it gets processed and the client is none the wiser.
>>
>> On Dec 14, 2016, at 1:33 PM, Gytis Trikleris <gtrikler at redhat.com> wrote:
>>>
>>> In this particular test case both coordinator and participants are on
>>> the same server. But they can also be running on different servers.
>>> Participant just contacts coordinator via URL provided wherever it is
>>> located.
>>>
>>>
>>> On 14/12/2016 18:19, Brian Stansberry wrote:
>>>
>>>> This can’t be done internally? Using an HTTP to communicate between
>>>> aspects of the server seems yuck.
>>>>
>>>> On Dec 14, 2016, at 2:58 AM, Gytis Trikleris <gtrikler at redhat.com>
>>>>> wrote:
>>>>>
>>>>> I need to load REST-AT participants from the crash recovery store and
>>>>> notify REST-AT coordinator (via REST API) of their URLs. This doesn't have
>>>>> to be done on the server start, but until it's done REST-AT coordinator
>>>>> recovery will be printing warnings because it won't be able to contact
>>>>> participants. So the sooner it's done the better, hence my question about a
>>>>> listener which could be invoked once the server completed boot-up.
>>>>>
>>>>> Gytis
>>>>>
>>>>> On 13/12/2016 23:45, Stuart Douglas wrote:
>>>>>
>>>>>> Why do you need to make a rest call while startup is taking place?
>>>>>>
>>>>>> Stuart
>>>>>>
>>>>>> On Wed, Dec 14, 2016 at 9:22 AM, Gytis Trikleris <gtrikler at redhat.com>
>>>>>> wrote:
>>>>>> Is there a way to make sure I'm making the service call not too early?
>>>>>>
>>>>>> Also, ControlledProcessStateService methods which are used in that
>>>>>> commit are deprecated. That's why I wasn't sure if it's OK for me to
>>>>>> use
>>>>>> them.
>>>>>>
>>>>>>
>>>>>> On 13/12/2016 22:34, Brian Stansberry wrote:
>>>>>>
>>>>>>> That commit you linked shows the mechanism for getting a
>>>>>>> notification of process state changes (inject ControlledProcessStateService
>>>>>>> and register a property change listener.)
>>>>>>>
>>>>>>> But, that commit is opening up the listener when it gets the
>>>>>>> notification, so if you listen for the same notification and make a call
>>>>>>> it’s going to be racy.
>>>>>>>
>>>>>>> On Dec 13, 2016, at 3:26 PM, Gytis Trikleris <gtrikler at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I'm wondering if there is a way to register a listener which would
>>>>>>>> be
>>>>>>>> invoked when server status has changed. More specifically when
>>>>>>>> application server completed start-up.
>>>>>>>>
>>>>>>>> The reason for that is that after [1] commit was introduced our rest
>>>>>>>> transaction tests started to fail. The cause seems to be rest
>>>>>>>> service
>>>>>>>> call during the start of one of our services. That call doesn't
>>>>>>>> necessarily have to be executed during the service start. However,
>>>>>>>> the
>>>>>>>> sooner it's done the better and if it would be possible to register
>>>>>>>> some
>>>>>>>> sort of callback to be invoked once start-up was done, that would
>>>>>>>> be great.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Gytis
>>>>>>>>
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://github.com/wildfly/wildfly/commit/d56cd18137d3acbcb5
>>>>>>>> 027744d5ce57f3ebc46d8e
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> wildfly-dev mailing list
>>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161215/84094571/attachment-0001.html
More information about the wildfly-dev
mailing list