Hi Sergio,
Thats because, when l2.l1.reconnect is enabled, there is a shutdown
hook in client which tries to close the channel graciously and there
by tell server NOT to open the reconnect window for it.
DSOClient.java
start() {
..
if (useOOOLayer) {
setReconnectCloseOnExit(this.channel);
}
setLoggerOnExit();
}
private void setReconnectCloseOnExit(final DSOClientMessageChannel
channel) {
CommonShutDownHook.addShutdownHook(new Runnable() {
public void run() {
channel.close(); ===> fires operation disabled event which
is trying to acquire a cluster lock.
}
});
}
thanks,
Manoj
On Jan 18, 2010, at 1:27 PM, Sergio Bossa wrote:
Thanks for your response Tim.
I understand it's a somewhat expected behavior, even if I would
have preferred an exception, but my question is now: why does it
hang only with l1 -> l2 reconnection enabled?
Thanks again!
Sergio Bossa
Sent by iPhone
Il giorno 18/gen/2010, alle ore 21.44, "Tim Eck"
<t...@terracottatech.com> ha scritto:
I think that looks more or less "expected" to me, but I'm sure
that is a
subjective opinion.
I think by definition "operationsDisabled()" means that you're no
longer
connected to the cluster. Now whether locks should hang (vs. throw
exceptions) is another matter.
From the stack trace it looks like this is happening when the L1
VM is
trying to exit. I wasn't aware that we fired operationsDisabled()
in that
path, but I think it makes sense.
-----Original Message-----
From: tc-dev-boun...@lists.terracotta.org [mailto:tc-dev-
boun...@lists.terracotta.org] On Behalf Of Sergio Bossa
Sent: Monday, January 18, 2010 4:19 AM
To: tc-dev
Subject: [tc-dev] L1 hanging when l2.l1reconnect.enabled set to true
Hi guys,
I noticed that with the "l2.l1reconnect.enabled" property set to
true,
I'm no more able to acquire clustered locks on "operationsDisabled"
method of cluster events API.
The L1 application hangs as follows:
"CommonShutDownHook" daemon prio=5 tid=0x0000000101afb000
nid=0x14af3a000 in Object.wait() [0x000000014af39000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x000000010a91ad80> (a
com.tcclient.util.concurrent.locks.ConditionObject$SyncCondition)
at java.lang.Object.wait(Object.java:485)
at
com.tc.object.bytecode.ManagerImpl.wait(ManagerImpl.java:812)
at
com.tc.object.bytecode.ManagerUtil.objectWait(ManagerUtil.java:508)
at
com.tcclient.util.concurrent.locks.ConditionObject.await
(ConditionObjec
t.java:103)
at
com.tc.object.locks.ClientLockManagerImpl.waitUntilRunning
(ClientLockMa
nagerImpl.java:588)
at
com.tc.object.locks.ClientLockManagerImpl.lock
(ClientLockManagerImpl.ja
va:89)
at
com.tc.object.bytecode.ManagerImpl.lock(ManagerImpl.java:718)
at
com.tc.object.bytecode.ManagerUtil.monitorEnter(ManagerUtil.java:
547)
at java.util.concurrent.locks.ReentrantLock.lock(Unknown
Source)
at
terrastore.cluster.impl.TCCluster.operationsDisabled
(TCCluster.java:156
)
at
com.tc.cluster.DsoClusterImpl.fireOperationsDisabledInternal
(DsoCluster
Impl.java:395)
at
com.tc.cluster.DsoClusterImpl.fireOperationsDisabled
(DsoClusterImpl.jav
a:388)
at
com.tc.object.handshakemanager.ClientHandshakeManagerImpl.notifyChan
nel
Event(ClientHandshakeManagerImpl.java:135)
at
com.tc.net.protocol.tcm.AbstractMessageChannel.fireEvent
(AbstractMessag
eChannel.java:244)
at
com.tc.net.protocol.tcm.AbstractMessageChannel.fireChannelClosedEven
t(A
bstractMessageChannel.java:135)
at
com.tc.net.protocol.tcm.AbstractMessageChannel.close
(AbstractMessageCha
nnel.java:147)
at
com.tc.object.DSOClientMessageChannelImpl.close
(DSOClientMessageChannel
Impl.java:88)
at
com.tc.object.DistributedObjectClient$2.run
(DistributedObjectClient.jav
a:726)
at
com.tc.util.CommonShutDownHook.run(CommonShutDownHook.java:37)
at java.lang.Thread.run(Thread.java:637)
Is it as expected? Is it a bug?
Thanks,
Cheers,
Sergio B.
--
Sergio Bossa
Software Passionate and Open Source Enthusiast.
URL: http://www.linkedin.com/in/sergiob
_______________________________________________
tc-dev mailing list
tc-dev@lists.terracotta.org
http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-dev mailing list
tc-dev@lists.terracotta.org
http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-dev mailing list
tc-dev@lists.terracotta.org
http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-dev mailing list
tc-dev@lists.terracotta.org
http://lists.terracotta.org/mailman/listinfo/tc-dev
