[JBoss JIRA] (AS7-4724) Sessions lost on server crash when using DIST SYNC mode (Lock is being held by null)
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-4724:
-----------------------------------
Summary: Sessions lost on server crash when using DIST SYNC mode (Lock is being held by null)
Key: AS7-4724
URL: https://issues.jboss.org/browse/AS7-4724
Project: Application Server 7
Issue Type: Bug
Components: Clustering
Affects Versions: 7.1.1.Final
Reporter: Radoslav Husar
Assignee: Paul Ferraro
Priority: Critical
Fix For: 7.1.2.Final (EAP)
It seems that the current failover tests have few failed requests when using DIST SYNC.
The client logging indicates that
{noformat}2012/05/06 17:04:20:041 EDT [WARN ][Runner - 123] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 100, received 0, Runner: 123>{noformat}
that the session was not found and created a new session instead.
The exceptions sorroundthing the errors
{noformat}
[JBossINF] 16:55:52,535 INFO [org.jboss.test.clusterbench.common.session.CommonHttpSessionServlet] (ajp-perf21-10.16.90.60-8009-44) New session created: -gjLvzZ7CdxcPVSlMbL1A1bK.perf21
2012/05/06 16:56:22:030 EDT [DEBUG][Thread-28] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - JBossStartup, server started!
[JBossINF] 16:57:49,978 INFO [org.jboss.as.clustering] (Incoming-10,null) JBAS010226: New cluster view for partition ejb: 4 (org.jboss.as.clustering.impl.CoreGroupCommunicationService$GroupView@6232c7b5 delta: -1, merge: false)
[JBossINF] 16:57:49,980 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-10,null) ISPN000094: Received new cluster view: [perf19/ejb|4] [perf19/ejb, perf21/ejb, perf20/ejb]
[JBossINF] 16:57:49,980 INFO [org.jboss.as.clustering] (Incoming-2,null) JBAS010226: New cluster view for partition web: 4 (org.jboss.as.clustering.impl.CoreGroupCommunicationService$GroupView@27782e36 delta: -1, merge: false)
[JBossINF] 16:57:49,981 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,null) ISPN000094: Received new cluster view: [perf19/web|4] [perf19/web, perf21/web, perf20/web]
[JBossINF] 16:58:52,192 INFO [org.jboss.as.clustering] (Incoming-19,null) JBAS010226: New cluster view for partition web: 5 (org.jboss.as.clustering.impl.CoreGroupCommunicationService$GroupView@2d942191 delta: 1, merge: false)
[JBossINF] 16:58:52,192 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-19,null) ISPN000094: Received new cluster view: [perf19/web|5] [perf19/web, perf21/web, perf20/web, perf18/web]
[JBossINF] 16:58:52,256 INFO [org.jboss.as.clustering] (Incoming-18,null) JBAS010226: New cluster view for partition ejb: 5 (org.jboss.as.clustering.impl.CoreGroupCommunicationService$GroupView@2f94ac91 delta: 1, merge: false)
[JBossINF] 16:58:52,257 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-18,null) ISPN000094: Received new cluster view: [perf19/ejb|5] [perf19/ejb, perf21/ejb, perf20/ejb, perf18/ejb]
[JBossINF] 16:59:56,589 INFO [org.jboss.as.clustering] (VERIFY_SUSPECT.TimerThread,web,perf21/web) JBAS010232: Suspected member: perf19/web
[JBossINF] 16:59:56,589 INFO [org.jboss.as.clustering] (VERIFY_SUSPECT.TimerThread,ejb,perf21/ejb) JBAS010232: Suspected member: perf19/ejb
[JBossINF] 16:59:56,694 INFO [org.jboss.as.clustering] (Incoming-11,null) JBAS010225: New cluster view for partition ejb (id: 6, delta: -1, merge: false) : [perf21/ejb, perf20/ejb, perf18/ejb]
[JBossINF] 16:59:56,694 INFO [org.jboss.as.clustering] (Incoming-1,null) JBAS010225: New cluster view for partition web (id: 6, delta: -1, merge: false) : [perf21/web, perf20/web, perf18/web]
[JBossINF] 16:59:56,695 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-11,null) ISPN000094: Received new cluster view: [perf21/ejb|6] [perf21/ejb, perf20/ejb, perf18/ejb]
[JBossINF] 16:59:56,695 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,null) ISPN000094: Received new cluster view: [perf21/web|6] [perf21/web, perf20/web, perf18/web]
[JBossINF] 17:00:58,915 INFO [org.jboss.as.clustering] (Incoming-7,null) JBAS010225: New cluster view for partition web (id: 7, delta: 1, merge: false) : [perf21/web, perf20/web, perf18/web, perf19/web]
[JBossINF] 17:00:58,916 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-7,null) ISPN000094: Received new cluster view: [perf21/web|7] [perf21/web, perf20/web, perf18/web, perf19/web]
[JBossINF] 17:00:58,974 INFO [org.jboss.as.clustering] (Incoming-4,null) JBAS010225: New cluster view for partition ejb (id: 7, delta: 1, merge: false) : [perf21/ejb, perf20/ejb, perf18/ejb, perf19/ejb]
[JBossINF] 17:00:58,974 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-4,null) ISPN000094: Received new cluster view: [perf21/ejb|7] [perf21/ejb, perf20/ejb, perf18/ejb, perf19/ejb]
[JBossINF] 17:02:02,386 INFO [org.jboss.as.clustering] (VERIFY_SUSPECT.TimerThread,ejb,perf21/ejb) JBAS010232: Suspected member: perf20/ejb
[JBossINF] 17:02:02,387 INFO [org.jboss.as.clustering] (VERIFY_SUSPECT.TimerThread,web,perf21/web) JBAS010232: Suspected member: perf20/web
[JBossINF] 17:02:02,445 INFO [org.jboss.as.clustering] (Incoming-5,null) JBAS010225: New cluster view for partition web (id: 8, delta: -1, merge: false) : [perf21/web, perf18/web, perf19/web]
[JBossINF] 17:02:02,450 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-5,null) ISPN000094: Received new cluster view: [perf21/web|8] [perf21/web, perf18/web, perf19/web]
[JBossINF] 17:02:02,463 INFO [org.jboss.as.clustering] (Incoming-4,null) JBAS010225: New cluster view for partition ejb (id: 8, delta: -1, merge: false) : [perf21/ejb, perf18/ejb, perf19/ejb]
[JBossINF] 17:02:02,463 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-4,null) ISPN000094: Received new cluster view: [perf21/ejb|8] [perf21/ejb, perf18/ejb, perf19/ejb]
[JBossINF] 17:02:21,486 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (ajp-perf21-10.16.90.60-8009-104) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on x2pULjT0wz2pS0AC1l0Osck6 on behalf of transaction GlobalTransaction:<perf21/web>:5824:remote. Lock is being held by null
[JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.newTimeoutException(AbstractTxLockingInterceptor.java:214)
[JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:195)
[JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAndRegisterBackupLock(AbstractTxLockingInterceptor.java:136)
[JBossINF] at org.infinispan.interceptors.locking.OptimisticLockingInterceptor$LockAcquisitionVisitor.visitPutKeyValueCommand(OptimisticLockingInterceptor.java:243)
[JBossINF] at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77)
[JBossINF] at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.acquireLocksVisitingCommands(OptimisticLockingInterceptor.java:318)
[JBossINF] at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.visitPrepareCommand(OptimisticLockingInterceptor.java:119)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
[JBossINF] at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:58)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
[JBossINF] at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
[JBossINF] at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:106)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
[JBossINF] at org.infinispan.interceptors.StateTransferLockInterceptor.handleWithRetries(StateTransferLockInterceptor.java:213)
[JBossINF] at org.infinispan.interceptors.StateTransferLockInterceptor.visitPrepareCommand(StateTransferLockInterceptor.java:85)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
[JBossINF] at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
[JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:131)
[JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:90)
[JBossINF] at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
[JBossINF] at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
[JBossINF] at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:70)
[JBossINF] at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:126)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:133)
[JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.perform(PrepareCommand.java:128)
[JBossINF] at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:127)
[JBossINF] at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:136)
[JBossINF] at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithRetry(InboundInvocationHandlerImpl.java:162)
[JBossINF] at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:114)
[JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:221)
[JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:201)
[JBossINF] at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:456)
[JBossINF] at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:363)
[JBossINF] at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:238)
[JBossINF] at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:543)
[JBossINF] at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130)
[JBossINF] at org.jgroups.JChannel.up(JChannel.java:716)
[JBossINF] at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1026)
[JBossINF] at org.jgroups.protocols.RSVP.up(RSVP.java:192)
[JBossINF] at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
[JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
[JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
[JBossINF] at org.jgroups.protocols.pbcast.GMS.up(GMS.java:889)
[JBossINF] at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
[JBossINF] at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:759)
[JBossINF] at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:365)
[JBossINF] at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:602)
[JBossINF] at org.jgroups.protocols.BARRIER.up(BARRIER.java:102)
[JBossINF] at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
[JBossINF] at org.jgroups.protocols.FD.up(FD.java:273)
[JBossINF] at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
[JBossINF] at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
[JBossINF] at org.jgroups.protocols.Discovery.up(Discovery.java:359)
[JBossINF] at org.jgroups.stack.Protocol.up(Protocol.java:363)
[JBossINF] at org.jgroups.protocols.TP.passMessageUp(TP.java:1180)
[JBossINF] at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1728)
[JBossINF] at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1710)
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
[JBossINF] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
[JBossINF]
{noformat}
...
{noformat}
[JBossINF] 17:02:40,549 ERROR [org.infinispan.transaction.tm.DummyTransaction] (ajp-perf21-10.16.90.60-8009-104) ISPN000109: beforeCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, transaction=DummyTransaction{xid=DummyXid{id=6307}, status=1}, lockedKeys=null, backupKeyLocks=null, viewId=8} org.infinispan.transaction.synchronization.SyncLocalTransaction@189b} org.infinispan.transaction.synchronization.SynchronizationAdapter@18ba: org.infinispan.CacheException: Could not prepare.
[JBossINF] at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:70)
[JBossINF] at org.infinispan.transaction.tm.DummyTransaction.notifyBeforeCompletion(DummyTransaction.java:230)
[JBossINF] at org.infinispan.transaction.tm.DummyTransaction.runPrepare(DummyTransaction.java:241)
[JBossINF] at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:86)
[JBossINF] at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:102)
[JBossINF] at org.jboss.as.clustering.web.impl.TransactionBatchingManager.endBatch(TransactionBatchingManager.java:75)
[JBossINF] at org.jboss.as.web.session.DistributableSessionManager.processSessionRepl(DistributableSessionManager.java:1512) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
[JBossINF] at org.jboss.as.web.session.DistributableSessionManager.storeSession(DistributableSessionManager.java:854) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
[JBossINF] at org.jboss.as.web.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:47) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
[JBossINF] at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:133) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
[JBossINF] at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:91) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
[JBossINF] at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:88) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
[JBossINF] at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:56) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
[JBossINF] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
[JBossINF] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.15.Final.jar:]
[JBossINF] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.15.Final.jar:]
[JBossINF] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.15.Final.jar:]
[JBossINF] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.15.Final.jar:]
[JBossINF] at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505) [jbossweb-7.0.15.Final.jar:]
[JBossINF] at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:445) [jbossweb-7.0.15.Final.jar:]
[JBossINF] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.15.Final.jar:]
[JBossINF] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
[JBossINF] Caused by: javax.transaction.xa.XAException
[JBossINF] at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:160)
[JBossINF] at org.infinispan.transaction.TransactionCoordinator.prepare(TransactionCoordinator.java:122)
[JBossINF] at org.infinispan.transaction.synchronization.SynchronizationAdapter.beforeCompletion(SynchronizationAdapter.java:68)
[JBossINF] ... 21 more
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] (AS7-4575) JNDI ObjectFactory should acccept parameters
by Ivica Loncar (JIRA)
Ivica Loncar created AS7-4575:
---------------------------------
Summary: JNDI ObjectFactory should acccept parameters
Key: AS7-4575
URL: https://issues.jboss.org/browse/AS7-4575
Project: Application Server 7
Issue Type: Feature Request
Components: Naming
Affects Versions: 7.1.1.Final
Reporter: Ivica Loncar
Assignee: John Bailey
Attachments: objectfactory_with_params.diff
object-factory binding should allow us to specify parameters that should be propagated to the ObjectFactory.
For example, Tomcat allows us to create URLResourceFactory that accepts parameters defined as attributes of Resource element in XML.
The configuration would loook like this:
{{
<subsystem xmlns="urn:jboss:domain:naming:1.1">
<bindings>
<object-factory name="java:global/url/google" module="net.croz.jboss.jndi.url" class="net.croz.jboss.jndi.url.URLResourceFactory" url="http://www.google.com"/>
</bindings>
</subsystem>
}}
I have implemented proof of a concept.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] Created: (AS7-1294) Don't inject into static fields/methods
by jaikiran pai (JIRA)
Don't inject into static fields/methods
---------------------------------------
Key: AS7-1294
URL: https://issues.jboss.org/browse/AS7-1294
Project: Application Server 7
Issue Type: Bug
Components: EE
Affects Versions: 7.0.0.Final
Reporter: jaikiran pai
Assignee: David Lloyd
The Java EE6 spec, section EE.5.2.5 says:
{quote}
The field or method may have any access qualifier (public, private, etc.). For all classes except application client
main classes, the fields or methods must not be static.
{quote}
Currently we even inject even into static fields/methods.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] (AS7-4102) Implement fallback mechanism for AS7 properties in pom.xml
by Pavel Janousek (JIRA)
Pavel Janousek created AS7-4102:
-----------------------------------
Summary: Implement fallback mechanism for AS7 properties in pom.xml
Key: AS7-4102
URL: https://issues.jboss.org/browse/AS7-4102
Project: Application Server 7
Issue Type: Sub-task
Affects Versions: 7.1.1.Final
Reporter: Pavel Janousek
Assignee: Ondrej Zizka
There are several places where is used fallback mechanism when some content from property is taken like:{code}static final String someIPproperty = System.getProperty("<some> key>", "localhost");{code}
The final decision based on (linked) AS7 devel discussion is leaving this approach and set-up this things in pom.xml's only.
After this task will be done, old approach will be leaved at all and every new patch will be forced to not use/include a such fallback mechanism only.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] Created: (JGRP-364) When using TCP_NIO, starting two nodes at the same time causes one of the nodes not to join group
by Matthew Todd (JIRA)
When using TCP_NIO, starting two nodes at the same time causes one of the nodes not to join group
-------------------------------------------------------------------------------------------------
Key: JGRP-364
URL: http://jira.jboss.com/jira/browse/JGRP-364
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Environment: linux 2.6 kernel x86_64 running java 1.5.0_06
Reporter: Matthew Todd
Assigned To: Bela Ban
I am testing a jgroups tcp_nio configuration using the draw demo.If I start up my 3 nodes one by one then everything works fine. However if I start up node 1, then attempt to start node 2 and 3 in parallel then only node 2 will work. Node 3 will be isolated and not see the other nodes and logs the following message:
org.jgroups.protocols.pbcast.ClientGmsImpl join
WARNING: join(192.158.70.200:7802) sent to 192.158.70.200:7800 timed out, retrying
I am starting the draw demo like this;
java -cp jgroups-all.jar:commons-logging.jar:concurrent.jar:jmxri.jar org.jgroups.demos.Draw -props test.xml
Here is the configuration for one of my nodes:
<config>
<TCP_NIO
bind_addr="192.158.70.200"
recv_buf_size="20000000"
send_buf_size="640000"
loopback="false"
discard_incompatible_packets="true"
max_bundle_size="64000"
max_bundle_timeout="30"
use_incoming_packet_handler="true"
use_outgoing_packet_handler="true"
down_thread="false" up_thread="false"
enable_bundling="true"
start_port="7800"
end_port="7800"
use_send_queues="false"
sock_conn_timeout="300" skip_suspected_members="true"
/>
<MPING timeout="2000" num_initial_members="3" mcast_addr="229.6.7.8"
bind_addr="192.158.70.200" down_thread="false" up_thread="false"/>
<MERGE2 max_interval="100000"
down_thread="false" up_thread="false" min_interval="20000"/>
<FD_SOCK down_thread="false" up_thread="false"/>
<VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false"/>
<pbcast.NAKACK max_xmit_size="60000"
use_mcast_xmit="false" gc_lag="0"
retransmit_timeout="300,600,1200,2400,4800"
down_thread="true" up_thread="true"
discard_delivered_msgs="true"/>
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
down_thread="false" up_thread="false"
max_bytes="400000"/>
<pbcast.GMS print_local_addr="true" join_timeout="3000"
down_thread="true" up_thread="true"
join_retry_timeout="2000" shun="true"
view_bundling="true"/>
<!-- <FC max_credits="2000000" down_thread="false" up_thread="false"
min_threshold="0.10"/>
<FRAG2 frag_size="60000" down_thread="false" up_thread="false"/> -->
<pbcast.STATE_TRANSFER/>
<!-- <pbcast.FLUSH down_thread="false" up_thread="false"/>-->
</config>
Node 2 and 3 have the same configuration except the port they bind to has been changed
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] Created: (JGRP-356) TCP_NIO: failure starting correctly with bundling enabled
by Bela Ban (JIRA)
TCP_NIO: failure starting correctly with bundling enabled
---------------------------------------------------------
Key: JGRP-356
URL: http://jira.jboss.com/jira/browse/JGRP-356
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Reporter: Bela Ban
Assigned To: Vladimir Blagojevic
Fix For: 2.5
Stack is (default tcp-nio.xml with bundling enabled), the error is:
$ jg Draw -props ./tcp-nio.xml
-------------------------------------------------------
GMS: address is 127.0.0.1:7800
-------------------------------------------------------
** View=[127.0.0.1:7800|0] [127.0.0.1:7800]
0 [WARN] [TimeScheduler.Thread] TimeScheduler._run(): task org.jgroups.protocols.TP$Bundler$BundlingTimer@1c65216 took 20921ms to execute, please check why it is taking so long. It is delaying other tasks
<config>
<TCP_NIO
recv_buf_size="20000000"
send_buf_size="640000"
loopback="false"
discard_incompatible_packets="true"
max_bundle_size="64000"
max_bundle_timeout="30"
use_incoming_packet_handler="true"
use_outgoing_packet_handler="false"
down_thread="false" up_thread="false"
enable_bundling="true"
start_port="7800"
use_send_queues="false"
sock_conn_timeout="300" skip_suspected_members="true"
reader_threads="8"
writer_threads="8"
processor_threads="8"
processor_minThreads="8"
processor_maxThreads="8"
processor_queueSize="100"
processor_keepAliveTime="-1"/>
<TCPPING timeout="3000"
down_thread="false" up_thread="false"
initial_hosts="${jgroups.tcpping.initial_hosts:localhost[7800],localhost[7801]}"
port_range="1"
num_initial_members="3"/>
<MERGE2 max_interval="100000"
down_thread="false" up_thread="false" min_interval="20000"/>
<FD_SOCK down_thread="false" up_thread="false"/>
<FD timeout="10000" max_tries="5" down_thread="false" up_thread="false" shun="true"/>
<VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false"/>
<pbcast.NAKACK max_xmit_size="60000"
use_mcast_xmit="false" gc_lag="0"
retransmit_timeout="300,600,1200,2400,4800"
down_thread="false" up_thread="false"
discard_delivered_msgs="true"/>
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
down_thread="false" up_thread="false"
max_bytes="400000"/>
<pbcast.GMS print_local_addr="true" join_timeout="3000"
down_thread="false" up_thread="false"
join_retry_timeout="2000" shun="true"
view_bundling="true"/>
<FC max_credits="2000000" down_thread="false" up_thread="false"
min_threshold="0.10"/>
<FRAG2 frag_size="60000" down_thread="false" up_thread="false"/>
<pbcast.STREAMING_STATE_TRANSFER down_thread="false" up_thread="false"
use_flush="true" use_reading_thread="true"/>
<!-- pbcast.STATE_TRANSFER down_thread="false" up_thread="false" use_flush="false"/ -->
<pbcast.FLUSH down_thread="false" up_thread="false"/>
</config>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] Created: (JGRP-346) Connection objects are removed from the ConnectionTable, but remain active on the system and eventually consume available system resources.
by Stuart Jensen (JIRA)
Connection objects are removed from the ConnectionTable, but remain active on the system and eventually consume available system resources.
-------------------------------------------------------------------------------------------------------------------------------------------
Key: JGRP-346
URL: http://jira.jboss.com/jira/browse/JGRP-346
Project: JGroups
Issue Type: Bug
Affects Versions: 2.3 SP1
Environment: SUSE Linux 9
Reporter: Stuart Jensen
Assigned To: Bela Ban
To duplicate the issue:
1) Create a four member cluster using the following configuration: (two member clusters exhibit the problem as well, just not as exaggerated)
TCP(start_port=7801):
TCPPING(initial_hosts=<ip addresses go here>;port_range=3;timeout=3500;num_initial_members=3;up_thread=true;down_thread=true):
MERGE2(min_interval=5000;max_interval=10000):
FD(shun=true;timeout=2500;max_tries=5;up_thread=true;down_thread=true):
VERIFY_SUSPECT(timeout=2000;down_thread=false;up_thread=false):
pbcast.NAKACK(down_thread=true;up_thread=true;gc_lag=100;retransmit_timeout=3000):
pbcast.STABLE(desired_avg_gossip=20000;down_thread=false;up_thread=false):
pbcast.GMS(join_timeout=5000;join_retry_timeout=3500;shun=true;print_local_addr=true;down_thread=true;up_thread=true)
2) I was running JGroups in a Tomcat servlet application. Start up the cluster. To determine the number of threads on Linux I executed the following commands:
ps -ef | grep tomcat
echo "" > catalina.out
kill -QUIT <pid from ps command above>
grep ".Sender \[" catalina.out | wc -l
You get the process id of Tomcat using the ps command. Then clear the content of the catalina.out file. The kill command causes the threads to be printed into the catalina.out file. Then the grep searches for and counts all of the "ConnectionTable.Connnection.Sender" threads that are currently active on the system.
3) Pick one of the cluster member boxes and pull the network cable out of the box such that all communication with the other three members is terminated.
4) After one or two minutes, replace the network cable.
5) Repeat the steps to determine the number of threads currently active on the system.
6) Repeat steps 3 through 5, each time watching the number of threads. Each iteration will cause more and more threads to be orphaned on the system. It seems to grow exponentially, after about 4 iterations we have around 300-400 Sender threads. The Receiver threads will be orphaned also in similar numbers.
After investigating the issue, I came up with the following "fix" which cleared the problem up.
In the file ConnectionTable.java there is a method called retainAll(). It appears that this method is called by the TCP protocol when a view change occurs. This method removes Connnections from the "Connection Pool" (member variable conns) but does not destroy them. We initially thought the reaper thread may clean them up, but since the Connection objects are actually removed from the Connection Pool, the reaper does not help the situation. As we watched our connections we noticed that the Connections orphaned by this routine were the ones filling up the system's set of threads. So, we added code to call destroy() on all of the Connection objects that retainAll() removes from the Connection Pool. The "diff" is provided below. Note that we did our change in the JGroups 2.3 SP1 file ConnectionTable.java. Scott Marlow did this diff for me, the same change, but applied to the BasicConnectionTable from the 2.4 source set.
Index: BasicConnectionTable.java
===================================================================
RCS file: /cvsroot/javagroups/JGroups/src/org/jgroups/blocks/BasicConnectionTable.java,v
retrieving revision 1.8
diff -r1.8 BasicConnectionTable.java
22,26c22
< import java.util.Map;
< import java.util.Iterator;
< import java.util.HashMap;
< import java.util.Vector;
< import java.util.Collection;
---
> import java.util.*;
263c259,289
< conns.keySet().retainAll(c);
---
> // conns.keySet().retainAll(c);
> ArrayList alConnsToDestroy = new ArrayList();
> synchronized(conns)
> {
> HashMap copy=new HashMap(conns);
> conns.keySet().retainAll(c);
> Set ks = copy.keySet();
> Iterator iter = ks.iterator();
> while (iter.hasNext())
> {
> Object oKey = iter.next();
> if (null == conns.get(oKey))
> { // This connection NOT in the resultant connection set
> Connection conn = (Connection)copy.get(oKey);
> if (null != conn)
> { // Destroy this connection
> alConnsToDestroy.add(conn);
> }
> }
> }
> }
> // All of the connections that were not retained must be destroyed
> // so that their resources are cleaned up.
> for (int a=0; a<alConnsToDestroy.size(); a++)
> {
> Connection conn = (Connection)alConnsToDestroy.get(a);
> if(log.isTraceEnabled())
> log.trace("Destroy this orphaned connection: " + conn);
> conn.destroy();
> }
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] Created: (JBCLUSTER-186) Implementations of Invoker should implement equals as an equality check rather than relying on Object.equals, this is important for cluster fail-over support
by Scott Marlow (JIRA)
Implementations of Invoker should implement equals as an equality check rather than relying on Object.equals, this is important for cluster fail-over support
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBCLUSTER-186
URL: http://jira.jboss.com/jira/browse/JBCLUSTER-186
Project: JBoss Clustering
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: JBoss as 4.0.4, although this seems to happen in 4.5 + 5.x as well.
Reporter: Scott Marlow
Assigned To: Scott Marlow
Priority: Minor
Part of how JRMPInvokerProxyHA handles fail-over includes removing the reference to the node that left the cluster. However, the dead node is not removed as an equality check is not implemented by certain Invoker implementations.
The relevant code in JRMPInvokerProxyHA is
protected void removeDeadTarget(Object target)
{
if (this.familyClusterInfo != null)
this.familyClusterInfo.removeDeadTarget (target);
}
The code in familyClusterInfo is:
public ArrayList removeDeadTarget(Object target)
{
synchronized (this)
{
ArrayList tmp = (ArrayList) targets.clone();
tmp.remove (target);
this.targets = tmp;
this.isViewMembersInSyncWithViewId = false;
}
return this.targets;
}
Since, we didn't include an equals test in many of the different Invoker implementations, the above "tmp.remove(target)" operation fails. The reason for the failure is due to the "targets" ArrayList changing on every invocation (to reflect the current cluster server membership list), a new "targets" is created (so of course comparing references later will not work.)
A similar problem occurs with the EJB2 load balancers after a cluster membership changes.
I think that these issues will be solved by implementing an equals test in the different invokers that can handle equality testing.
PooledInvokerProxy should implement equals based on ServerAddress.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] Created: (JGRP-371) TCP_NIO with SSL
by Bela Ban (JIRA)
TCP_NIO with SSL
----------------
Key: JGRP-371
URL: http://jira.jboss.com/jira/browse/JGRP-371
Project: JGroups
Issue Type: Feature Request
Affects Versions: 2.4
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.5
Attachments: ssl-nio.jar
>From Hal Hildebrand:
Attached are the sources to allow a new protocol stack which uses SSL over
NIO. This protocol stack element provides security and authentication
(using client side authentication) for a JGroups TCP stack using NIO.
This required two minor modifications in the ConnectionTableNIO class.
These modifications allow one to subclass to create a connection table which
uses SSL for the connections. Finally, there is a new protocol stack
element, SSL_NIO, which one can add to a stack to make use of it.
Regardless of whether this makes it into the codeline of JGroups, it would
be nice to have the changes to ConnectionTableNIO make it into the mainline,
as I currently have to overwrite the original class to easily implement this
- the last thing I want to do is fork ConnectionTableNIO ;) I'd rather just
subclass it. The mods are simple and innocuous (marked with "HSH").
Right now, the SSL_NIO needs to be configured with an SSLSocketFactory. I
didn't bother with integrating with the normal JGroups mechanism using
properties from the configuration because I consider it inherently insecure
to ensconce my passwords in configuration files. But the changes to enable
this are straight forward. Currently, to configure the factory for the
protocol layer, do something like the following before connecting your
channel:
// Construct your Jchannel
JChannel jchannel = ...
// Access your protocol stack
ProtocolStack protocolStack = jchannel.getProtocolStack();
// Retrieve the SSL_NIO protocol layer
SSL_NIO protocol = (SSL_NIO) protocolStack.findProtocol("SSL_NIO");
// Create your SSLSocketFactory
SSLSocketFactory socketFactory = ....
// Set up the protocol
protocol. SetSocketFactory(socketFactory);
// Connect your channel
jchannel.connnect("my-group");
Cheers.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months