Re: [wildfly-dev] WildFly status listener

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(a)redhat.com&gt; 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(a)redhat.com&gt; >>>> 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(a)redhat.com&gt; >>>>> 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(a)redhat.com&gt; >>>>>>> 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(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>> >>>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>>>