[wildfly-dev] WildFly status listener
Gytis Trikleris
gtrikler at redhat.com
Wed Dec 14 17:39:18 EST 2016
I agree, and my intention when starting this thread was to find the best
place to move that call to. I'll try registering similar listener as in
your commit. That should free-up a service boot-up thread.
Gytis
On 14/12/2016 23:21, Stuart Douglas wrote:
> 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
> <mailto: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 <mailto: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 <mailto: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
> <mailto: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
> <mailto: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/d56cd18137d3acbcb5027744d5ce57f3ebc46d8e
> <https://github.com/wildfly/wildfly/commit/d56cd18137d3acbcb5027744d5ce57f3ebc46d8e>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> <mailto:wildfly-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> <mailto:wildfly-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20161214/9c9d9cf1/attachment.html
More information about the wildfly-dev
mailing list