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.
On 14/12/2016 23:21, Stuart Douglas wrote:
In that case you should probably move the rest call out of the
start, and have it processed by a separate thread.
Its probably not great having server start dependent on an external
service being up anyway.
On Thu, Dec 15, 2016 at 7:10 AM, Gytis Trikleris <gtrikler(a)redhat.com
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 <mailto:email@example.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
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.
On 13/12/2016 23:45, Stuart Douglas wrote:
Why do you need to make a rest call while
startup is taking place?
On Wed, Dec 14, 2016 at 9:22 AM, Gytis
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
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
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 
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.
wildfly-dev mailing list
wildfly-dev mailing list