Quantcast

WildFly status listener

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

WildFly status listener

Gytis Trikleris-2
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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WildFly status listener

Brian Stansberry
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 <[hidden email]> 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
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WildFly status listener

Gytis Trikleris-2
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 <[hidden email]> 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
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WildFly status listener

Stuart Douglas
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 <[hidden email]> 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 <[hidden email]> 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
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WildFly status listener

Brian Stansberry
In reply to this post by Gytis Trikleris-2

> On Dec 13, 2016, at 4:22 PM, Gytis Trikleris <[hidden email]> 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.
>

I deprecated that code when wrote with a meaning more like “@Experimental”. But it’s still valid years later so https://github.com/wildfly/wildfly-core/pull/2030 will take care of that.

> 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 <[hidden email]> 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
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WildFly status listener

Gytis Trikleris-2
In reply to this post by Stuart Douglas

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 <[hidden email]> 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 <[hidden email]> 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
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WildFly status listener

Brian Stansberry
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>> >>
>> >> _______________________________________________
>> >> wildfly-dev mailing list
>> >> [hidden email]
>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WildFly status listener

Gytis Trikleris-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WildFly status listener

Brian Stansberry
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>>>
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WildFly status listener

Gytis Trikleris-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> wildfly-dev mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WildFly status listener

Stuart Douglas
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WildFly status listener

Gytis Trikleris-2

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev





_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WildFly status listener

Brian Stansberry
Don’t do it in the property change callback thread itself.

> On Dec 14, 2016, at 4:39 PM, Gytis Trikleris <[hidden email]> wrote:
>
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WildFly status listener

Bob McWhirter
In reply to this post by Stuart Douglas

Service start should be quick and non-blocking or call async and run in a different thread and signal completion when done. Generally speaking. 


On Wed, Dec 14, 2016 at 5:30 PM Stuart Douglas <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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





_______________________________________________


wildfly-dev mailing list


[hidden email]


https://lists.jboss.org/mailman/listinfo/wildfly-dev




_______________________________________________


wildfly-dev mailing list


[hidden email]


https://lists.jboss.org/mailman/listinfo/wildfly-dev













_______________________________________________

wildfly-dev mailing list

[hidden email]

https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WildFly status listener

Gytis Trikleris-2
In reply to this post by Brian Stansberry
Thanks for the explanations. I'll move the http call to the recovery
module, so it will be executed in the recovery thread.

Gytis


On 15/12/2016 00:07, Brian Stansberry wrote:

> Don’t do it in the property change callback thread itself.
>
>> On Dec 14, 2016, at 4:39 PM, Gytis Trikleris <[hidden email]> wrote:
>>
>> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Loading...