[STABLE] Reset suspended flag to true, this should never hap

[sheckler]

Starting the second cluster node, I see following log message

[STABLE] Reset suspended flag to true, this should never happen: check why RESUME_STABLE has not been received

What does it mean?

Stefan

P.S. using JBoss 3.2.7

[belaban]

Hard to say. This message means that a timer has kicked in as a second line of defense, to prevent indefinite blocking. One reason could be that your system was severely overloaded, and you never got the RESUME_STABLE event. Another reason: your state was large (is that true ?), and state transfer took a long time.
I'd have to look at the logs to be able to say more about this.

[litflyhorse]

This happend to me now and then, but not affect server running.
Except this log message there is no other log message about [STABLE]

[sheckler]

In my case it happend during startup of second jboss node within a cluster. The message appeared several times after the initialisation of clustered session beans (saw the instantiation of securityProxies shortly before).
It is not reproducable.
I had a misconfiguration within JBoss MQ (2 JBossMQ instances where sharing the same database). Since I fixed this problem, I could not observer the above message, but I dont't know if there was a correlation.
Stefan

[belaban]

Did this cause incorrect behavior ?
I'd say 'no'...

[sheckler]

It did, but not at startup time, when the log message was raised. The incorrect behavior occured with heavy load of JMS later on.
So I think there is no correlation, but nevertheless I dont' see the message any longer. Maybe net work problems/configuration could have been the problem at that time?

[sheckler]

To be exact: the JMS misconfiguration did cause incorrect behaviour, not the [STABLE] message.

[belaban]

JMS ? This is JGroups, and has nothing to do with JMS. Only possibly with HA-JMS, but I think this is unrelated

[sheckler]

It was HA-JMS

[ntsankov]

Hard to say. This message means that a timer has kicked in as a second line of defense, to prevent indefinite blocking. One reason could be that your system was severely overloaded, and you never got the RESUME_STABLE event. Another reason: your state was large (is that true ?), and state transfer took a long time.
I'd have to look at the logs to be able to say more about this.

Hello,
I have similar problem: the second node is started extremely slow (30 min.) and the mentioned message is logged. The system was idle at the time, so I guess I have the large state situation. Correct me if I am wrong, but for me state means SFSBs and HTTP sessions. And I don't have a single SFSB or http client (the first node is started fully and sits idle, then the second node is started and meanwhile noone is using the application).
Any ideas?

Thanx in advance,

nts