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
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> 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
> 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 Trikleris <gtrikler(a)redhat.com>
>> 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
>> 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
>>> 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>
>>>> I'm wondering if there is a way to register a listener which would
>>>> 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
>>>> sort of callback to be invoked once start-up was done, that would be
>>>> wildfly-dev mailing list
>> wildfly-dev mailing list