Re: Behavior of init() for clustered singleton

[Yakov Zhdanov]

Please provide app logs after the issue gets reproduced.

--Yakov

2016-04-08 19:20 GMT+03:00 dstieglitz :

> Ok I added the debug statements:
>
>
> https://github.com/dstieglitz/grails-ignite/blob/v0.4.x/src/java/org/grails/ignite/DistributedSchedulerServiceImpl.java
>
> Let me know if you want me to report anything from our application.
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/Behavior-of-init-for-clustered-singleton-tp3819p4025.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: Behavior of init() for clustered singleton

[dstieglitz]

Hi guys:

So, we've investigated this a bit further and we think the service is
actually working, but the issue is that our debug display is showing null
for some objects. We think this is because the service and those objects
live on another node, and we're seeing null because they are not serializing
across the grid. 

Is that possible? If there are some objects in the service that don't
serialize and you try to access them from a different node would they just
print out as null?

Dan



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Behavior-of-init-for-clustered-singleton-tp3819p4013.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Behavior of init() for clustered singleton

[vkulichenko]

Hi,

The try-catch block in scheduleWithCron method just wraps the original
exception into DistributedRunnableException and rethrows it. It is then
propagated to the node that invoked the service proxy.

Do you expect different behavior?

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Behavior-of-init-for-clustered-singleton-tp3819p4009.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Behavior of init() for clustered singleton

[Yakov Zhdanov]

Your examples seems correct to me.
1. What does it mean by "goes null"?
2. I do not see any assignments other than instantiation in init() method.
3. You confirm that service worked OK on some node but after some time with
no topology changes it starts to throw NPE, correct? Can you please share
the stack trace? Maybe it can reveal some details we missing now.

--Yakov

2016-04-06 3:10 GMT+03:00 dstieglitz :

> Following up on this...
>
> Sorry for the vague description of the problem, but we are experiencing
> objects "going null" (as if they were garbage collected?) in our clustered
> singleton.
>
> We have an instance variable of an object that is initialized in the
> service
> init() method. We have confirmed that on topology change, the object is
> properly re-initialized. However, after some period of time, for example,
> overnight, the object "goes null."
>
> Are we doing this correctly? Should we store the object in the cluster?
>
> The schedule class is here:
>
> https://github.com/dstieglitz/grails-ignite/blob/v0.4.x/src/java/org/grails/ignite/DistributedSchedulerServiceImpl.java
>
> The object in question is the "DistributedScheduledThreadPoolExecutor"
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/Behavior-of-init-for-clustered-singleton-tp3819p3944.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: Behavior of init() for clustered singleton

[dstieglitz]

Following up on this...

Sorry for the vague description of the problem, but we are experiencing
objects "going null" (as if they were garbage collected?) in our clustered
singleton.

We have an instance variable of an object that is initialized in the service
init() method. We have confirmed that on topology change, the object is
properly re-initialized. However, after some period of time, for example,
overnight, the object "goes null."

Are we doing this correctly? Should we store the object in the cluster?

The schedule class is here:
https://github.com/dstieglitz/grails-ignite/blob/v0.4.x/src/java/org/grails/ignite/DistributedSchedulerServiceImpl.java

The object in question is the "DistributedScheduledThreadPoolExecutor"



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Behavior-of-init-for-clustered-singleton-tp3819p3944.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Behavior of init() for clustered singleton

[Dmitriy Setrakyan]

On Thu, Mar 31, 2016 at 8:58 AM, dstieglitz 
wrote:

> Hi folks:
>
> We're trying to deploy a clustered singleton service. In our Service
> implementation object we have a reference to another object that is
> initialized in the init() method.
>
> We've observed that upon topology change, this object can go "null."
>

This is normal, since the service state is not moved. All Ignite does is
make sure that the service is immediately started on another node and calls
“init()” again.


>  Is init() called again when the
> service has to migrate to a new node?
>

Yes.


>
> Dan
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/Behavior-of-init-for-clustered-singleton-tp3819.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>