[JBoss JIRA] (WFLY-967) ClassLoader memory leak with JSF
by Stan Silvert (JIRA)
[ https://issues.jboss.org/browse/WFLY-967?page=com.atlassian.jira.plugin.s... ]
Stan Silvert commented on WFLY-967:
-----------------------------------
I'm not seeing an actual leak. The instances do go away eventually. It looks like something is timing out after 30 minutes, which makes these instances eligible for GC. That made me thing it had something to do with session timeout. But I'm not sure at this point. When I tried setting session timeout to a lower value, I found a bug in Undertow, UNDERTOW-42.
Can you try to replicate my results on your end?
> ClassLoader memory leak with JSF
> --------------------------------
>
> Key: WFLY-967
> URL: https://issues.jboss.org/browse/WFLY-967
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Reporter: Vlad Arkhipov
> Assignee: Stan Silvert
> Priority: Critical
> Attachments: war-leak.tar.gz
>
>
> JSF application's classes are not unloaded properly when undeployed. The test case is in the attachment. Steps to reproduce:
> # mvn package
> # deploy war-leak.war
> # open http://localhost:8080/war-leak
> # undeploy war-leak.war
> # analyze a heap dump to find unloaded ModuleClassLoader of war-leak.war
> References to the WAR classes are hold by java.beans.Introspector caches. It seems to be a known bug (feature?). For example Tomcat automatically invokes java.beans.Introspector.flushCaches() when WAR undeploys. There is also IntrospectorCleanupListener in Spring for the same purpose.
> http://wiki.apache.org/commons/Logging/UndeployMemoryLeak
> http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (JGRP-1610) LockingService and rpc on the same cluster, tryLock() hangs
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1610?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1610:
--------------------------------
OK, it is clear why this fails:
- A invokes a *synchronous* (blocking) RPC on B
- UNICAST delivers the RPC from A at B
- The RPC tries to acquire the lock from A (who already holds it)
- A sends back a LOCK-DENIED unicast to B
- However, because B is already processing the RPC from A; the LOCK-DENIED messages won't get processed until the RPC returns. However, the RPC will only return when the lock has been granted or denied
==> A classic deadlock !
SOLUTION:
#1 Invoke the initial RPC as ASYNC RPC, or hold a future to it
#2 JGroups sends all messages which have no ordering contraints as OOBs, e.g. LOCK-GRANTED / LOCK-DENIED
> LockingService and rpc on the same cluster, tryLock() hangs
> -----------------------------------------------------------
>
> Key: JGRP-1610
> URL: https://issues.jboss.org/browse/JGRP-1610
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
> Attachments: RpcLockingTest.java
>
>
> Hi,
> Yes, the sequence diagram only depicted the second part of my description.
> Anyway, I've attached a test file that reproduce the problem.
> It contains two test cases, one where the coordinator of the lock is the one who
> sends the message first, and a second case where the non-coordinator sends
> the message first.
> In the first case the receiver, non-coordinator, will hang in tryLock. In the second
> case though, everything works fine.
> Regards,
> Daniel Olausson
> On 25 March 2013 16:15, Bela Ban <belaban(a)yahoo.com> wrote:
> Hi Daniel,
> the sequence diagram differs from your description, can you submit a
> test case (e.g. copy MessageDispatcherRSVPTest and modify it), so I can
> take a look ?
> I assume your RPCs are blocking (sync) and non-OOB ? Could be a
> recursive invocation, where FIFO order (default) leads to a distributed
> deadlock.
> A test case would clarify what you want to do, and if I can reproduce
> the problem, I can fix it.
> On 3/25/13 1:54 PM, Daniel Olausson wrote:
> > Hi,
> >
> > We trying to use the same channel for our lockingService and
> > rpcDispatcher. But we are noticing some weird behavior.
> >
> > The end result is that lock.tryLock(lockName) never returns, which it
> > should always do.
> >
> > This happens when we do the following:
> >
> > On computer A, we lock the lock.
> > Do a rpc to a function on computer B, this function tries to take the
> > lock(lock.tryLock(lockName)), but it can't because the lock is locked.
> > This is correct behavior.
> > Computer A unlocks the lock.
> >
> > On computer B we now do the same procedure, we lock the lock and do a
> > rpc to computer A, but here is when the strange thing happens. Computer
> > A tries to take the lock by executing tryLock, but it never returns.
> >
> > Here is a sequence diagram:
> > http://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgQXV0aGVudGljY...
> >
> >
> > In this example we use the standard udp.xml with <CENTRAL_LOCK/> added
> > on the top of the stack. Everything works if we use PEER_LOCK but then
> > we need the messages to arrive in the same order everywhere, e.g. atomic
> > broadcast.
> >
> > It also works if we use different clusters for locking and rpc, but it
> > would be convenient if we could use the same cluster.
> >
> >
> > Is it recommended to use the same channel for different services?
> >
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (DROOLS-111) Ruleflow group activation/deactivation calls wrong listener methods
by Ales Dolecek (JIRA)
[ https://issues.jboss.org/browse/DROOLS-111?page=com.atlassian.jira.plugin... ]
Ales Dolecek updated DROOLS-111:
--------------------------------
Summary: Ruleflow group activation/deactivation calls wrong listener methods (was: Ruleflow group activation/deactivation calls weong listener methods)
> Ruleflow group activation/deactivation calls wrong listener methods
> -------------------------------------------------------------------
>
> Key: DROOLS-111
> URL: https://issues.jboss.org/browse/DROOLS-111
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Reporter: Ales Dolecek
> Assignee: Mark Proctor
> Priority: Minor
> Labels: listeners
> Original Estimate: 10 minutes
> Remaining Estimate: 10 minutes
>
> Method org.drools.impl.StatefulKnowledgeSessionImpl$AgendaEventListenerWrapper.beforeRuleFlowGroupActivated delegates to listener.afterRuleFlowGroupActivated.
> Method beforeRuleFlowGroupDeactivated delegates to listener.afterRuleFlowGroupDeactivated.
> Thus when (de)activating ruleflow-group the before methods of any registered listener are NOT invoked while the after methods are invoked TWICE.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (DROOLS-111) Ruleflow group activation/deactivation calls weong listener methods
by Ales Dolecek (JIRA)
Ales Dolecek created DROOLS-111:
-----------------------------------
Summary: Ruleflow group activation/deactivation calls weong listener methods
Key: DROOLS-111
URL: https://issues.jboss.org/browse/DROOLS-111
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.5.0.Final
Reporter: Ales Dolecek
Assignee: Mark Proctor
Priority: Minor
Method org.drools.impl.StatefulKnowledgeSessionImpl$AgendaEventListenerWrapper.beforeRuleFlowGroupActivated delegates to listener.afterRuleFlowGroupActivated.
Method beforeRuleFlowGroupDeactivated delegates to listener.afterRuleFlowGroupDeactivated.
Thus when (de)activating ruleflow-group the before methods of any registered listener are NOT invoked while the after methods are invoked TWICE.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (AS7-6079) EJB 2.1 CMP configuration options missing (sync-on-commit-only, insert-after-ejb-post-create, call-ejb-store-on-clean)
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/AS7-6079?page=com.atlassian.jira.plugin.s... ]
Wolf-Dieter Fink commented on AS7-6079:
---------------------------------------
Abhi,
the commit options are not available in AS7.
There are no distributed caches.
The entity is cached local as long as the transaction is active and destroyed after commit/rollback.
This is the same as commit-option=C before.
> EJB 2.1 CMP configuration options missing (sync-on-commit-only, insert-after-ejb-post-create, call-ejb-store-on-clean)
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6079
> URL: https://issues.jboss.org/browse/AS7-6079
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.0.Alpha1, 7.1.3.Final (EAP)
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: EAP 6.1.0.Alpha (7.2.0.Final), 7.1.4.Final (EAP)
>
>
> In JBoss AS 7, EJB 2.1 CMP beans cannot configure some options such as sync-on-commit-only and insert-after-ejb-post which were configurable in previous versions of JBoss.
> Should also confirm how to configure the rest of the options that were available previously.
> <container-configuration>
> <container-name>Clustered CMP 2.x EntityBean</container-name>
> <call-logging>false</call-logging>
> <invoker-proxy-binding-name>clustered-entity-rmi-invoker</invoker-proxy-binding-name>
> <sync-on-commit-only>false</sync-on-commit-only>
> <insert-after-ejb-post-create>false</insert-after-ejb-post-create>
> <container-interceptors>
> ...
> </container-interceptors>
> <instance-pool>org.jboss.ejb.plugins.EntityInstancePool</instance-pool>
> <instance-cache>org.jboss.ejb.plugins.EntityInstanceCache</instance-cache>
> <persistence-manager>org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager</persistence-manager>
> <locking-policy>org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock</locking-policy>
> <container-cache-conf>
> <cache-policy>org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy</cache-policy>
> <cache-policy-conf>
> <min-capacity>50</min-capacity>
> <max-capacity>1000000</max-capacity>
> <overager-period>300</overager-period>
> <max-bean-age>600</max-bean-age>
> <resizer-period>400</resizer-period>
> <max-cache-miss-period>60</max-cache-miss-period>
> <min-cache-miss-period>1</min-cache-miss-period>
> <cache-load-factor>0.75</cache-load-factor>
> </cache-policy-conf>
> </container-cache-conf>
> <container-pool-conf>
> <MaximumSize>100</MaximumSize>
> </container-pool-conf>
> <commit-option>B</commit-option>
> </container-configuration>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (JGRP-1621) NPE on Locking.handleDeleteLockRequest
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1621?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1621:
--------------------------------
* Note that 2.12.x is an unsupported and out-of-date release
* I suggest try your code with a recent version, e.g. 3.2.8. The NPE you listed doesn't exist in 3.x
* You seem to have a cluster split, or at least member which aren't part of the cluster. This always slows down things, I suggest you go over your config and increase timeouts for FD/FD_ALL.
* Even better: copy udp.xml or tcp.xml from 3.2.8, and modify it if needed
> NPE on Locking.handleDeleteLockRequest
> --------------------------------------
>
> Key: JGRP-1621
> URL: https://issues.jboss.org/browse/JGRP-1621
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.12.1
> Reporter: freeliuade freeliuade
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> meet NPE on Locking.handleDeleteLockRequest, this NPE seems happens on the network full bandwidth.
> and it seems this exception will result in a lock can't be unlock.
> I'm pretty sure a locker has called unlock, but using LockService.printLocks() still can find the locker is be holding by a thread.
> below is the log:
> 03:00:00,881 WARN [GMS] hyliuds2-8321: not member of view [hyliuds1-33648|2] [hyliuds1-33648]; discarding it
> 03:00:00,890 WARN [GMS] hyliuds2-30414: not member of view [hyliuds1-3567|4] [hyliuds1-3567, node2-9324, node2-33852]; discarding it
> 03:00:00,886 WARN [GMS] hyliuds2-13134: not member of view [hyliuds1-13050|4] [hyliuds1-13050, node2-62142, node2-26805]; discarding it
> 03:00:00,924 WARN [GMS] hyliuds2-10154: not member of view [hyliuds1-51819|4] [hyliuds1-51819, node2-14763, node2-26168]; discarding it
> 03:00:01,264 WARN [GMS] jnp://10.101.7.172:1100: not member of view [jnp://10.101.7.24:1100|2] [jnp://10.101.7.24:1100]; discarding it
> 03:00:02,368 WARN [VIEW_SYNC] discarding view as I (hyliuds2-30414) am not member of view ([hyliuds1-3567|4] [hyliuds1-3567, node2-9324, node2-33852])
> 03:00:03,659 WARN [GMS] hyliuds2-13134: failed to collect all ACKs (expected=4) for view MergeView::[node2-62142|5] [node2-62142, hyliuds2-13134, node2-26805, hyliuds1-13050], subgroups=[[hyliuds1-13050|4] [hyliuds1-13050, node2-62142, node2-26805], [hyliuds2-13134|3] [hyliuds2-13134]] after 2000ms, missing ACKs from [node2-62142, node2-26805]
> 03:00:06,019 INFO [DomainManager] Installing App sla in domain DefaultDomain.
> 03:00:06,021 INFO [DomainManager] App sla is installed in domain DefaultDomain.
> 03:00:19,321 INFO [StateCache] Accept a new Node list "[jnp://10.101.7.24:1100, jnp://10.101.7.172:1100]"
> 03:00:33,586 WARN [VIEW_SYNC] discarding view as I (hyliuds2-30414) am not member of view ([hyliuds1-3567|4] [hyliuds1-3567, node2-9324, node2-33852])
> 03:00:50,634 INFO [StateCache] Accept a new Node list "[jnp://10.101.7.24:1100, jnp://10.101.7.172:1100]"
> 03:01:03,585 WARN [VIEW_SYNC] discarding view as I (hyliuds2-30414) am not member of view ([hyliuds1-3567|4] [hyliuds1-3567, node2-9324, node2-33852])
> 03:01:30,951 INFO [DomainManager] Installing App dojoclient in domain DefaultDomain.
> 03:01:30,971 INFO [DomainManager] App dojoclient is installed in domain DefaultDomain.
> 03:01:41,450 WARN [VIEW_SYNC] discarding view as I (hyliuds2-10154) am not member of view ([hyliuds1-51819|4] [hyliuds1-51819, node2-14763, node2-26168])
> 03:01:49,799 WARN [VIEW_SYNC] discarding view as I (hyliuds2-30414) am not member of view ([hyliuds1-3567|4] [hyliuds1-3567, node2-9324, node2-33852])
> 03:02:02,298 WARN [VIEW_SYNC] discarding view as I (hyliuds2-10154) am not member of view ([hyliuds1-51819|4] [hyliuds1-51819, node2-14763, node2-26168])
> 03:03:33,370 WARN [VIEW_SYNC] discarding view as I (hyliuds2-10154) am not member of view ([hyliuds1-51819|4] [hyliuds1-51819, node2-14763, node2-26168])
> 03:04:26,623 WARN [GMS] hyliuds2-8321: not member of view [hyliuds1-33648|4] [hyliuds1-33648]; discarding it
> 03:04:35,922 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:04:35,922 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:04:37,106 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:04:53,227 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:04:53,227 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:04:53,227 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:04:53,228 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:04:53,228 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:04:53,527 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:04:54,460 INFO [DomainManager] Deploying project "/apps/sla/projects/SLAAppletProject$Deployment" with release tag "TipOfTrunk" and deployment configuration "Deployment". The overwrite flag is true. The required Runtime Server is "DefaultPool/". The required Feed Server is "auto". The required Data Source for Runtime Server is "auto". The required Data Source for Feed Server is "auto".
> 03:04:54,837 INFO [DomainManager] Project "/apps/sla/projects/SLAAppletProject$Deployment" has been dispatched with Runtime Server "DefaultPool/rs2", Feed Server "fs", Runtime Server Data Source "/vitria/m3o/datasource/DefaultDomain/datasource", Feed Server Data Source "/vitria/m3o/datasource/DefaultDomain/datasource".
> 03:04:54,986 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:04:54,987 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:04:56,972 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:05:03,650 INFO [DomainManager] Data Source "/vitria/m3o/datasource/DefaultDomain/datasource" was deployed to RuntimeServer "DefaultPool/rs2".
> 03:05:03,692 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:05:03,692 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:05:04,387 INFO [DomainManager] Data Source "/vitria/m3o/datasource/DefaultDomain/datasource" was deployed to FeedServer "fs".
> 03:05:04,956 INFO [DomainManager] Feed "/apps/sla/projects/SLAAppletProject$Deployment/Vitria/Feed/EventSourceExceptionFeed" was deployed to FeedServer "fs".
> 03:05:05,000 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:05:05,001 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:05:05,994 INFO [DomainManager] Feed "/apps/sla/projects/SLAAppletProject$Deployment/Feeds/KPINotifications" was deployed to FeedServer "fs".
> 03:05:06,991 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:05:11,047 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:05:13,003 INFO [DomainManager] Project "/apps/sla/projects/SLAAppletProject$Deployment" successfully deployed on server "DefaultPool/rs2".
> 03:05:13,007 INFO [DomainManager] Notify an event with type "Deploy".
> 04:57:15,746 WARN [NAKACK] hyliuds2-10154: dropped message from hyliuds1-51819 (not in table [node2-14763, node2-26168, hyliuds2-10154]), view=[node2-14763|6] [node2-14763, hyliuds2-10154, node2-26168]
> 04:57:15,785 WARN [NAKACK] hyliuds2-10154: dropped message from hyliuds1-51819 (not in table [node2-14763, node2-26168, hyliuds2-10154]), view=[node2-14763|6] [node2-14763, hyliuds2-10154, node2-26168]
> 04:57:19,956 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|7] [hyliuds2-8321]
> 04:57:35,009 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|7] [hyliuds2-8321]
> 04:57:43,024 ERROR [UNICAST] couldn't deliver message [dst: hyliuds2-8321, src: hyliuds1-33648 (3 headers), size=95 bytes, flags=DONT_BUNDLE]
> java.lang.NullPointerException
> at org.jgroups.protocols.Locking.handleDeleteLockRequest(Locking.java:505)
> at org.jgroups.protocols.Locking.up(Locking.java:243)
> at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:150)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:189)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:891)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:246)
> at org.jgroups.protocols.VIEW_SYNC.up(VIEW_SYNC.java:170)
> at org.jgroups.protocols.UNICAST.handleDataReceived(UNICAST.java:613)
> at org.jgroups.protocols.UNICAST.up(UNICAST.java:294)
> at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:703)
> at org.jgroups.protocols.BARRIER.up(BARRIER.java:119)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:133)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:177)
> at org.jgroups.protocols.FD.up(FD.java:275)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:275)
> at org.jgroups.protocols.MERGE2.up(MERGE2.java:209)
> at org.jgroups.protocols.Discovery.up(Discovery.java:293)
> at org.jgroups.protocols.PING.up(PING.java:69)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1109)
> at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1665)
> at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1647)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (JGRP-1621) NPE on Locking.handleDeleteLockRequest
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1621?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1621.
----------------------------
Resolution: Rejected
Please reopen if 3.2.8 doesn't fix the issue.
> NPE on Locking.handleDeleteLockRequest
> --------------------------------------
>
> Key: JGRP-1621
> URL: https://issues.jboss.org/browse/JGRP-1621
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.12.1
> Reporter: freeliuade freeliuade
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> meet NPE on Locking.handleDeleteLockRequest, this NPE seems happens on the network full bandwidth.
> and it seems this exception will result in a lock can't be unlock.
> I'm pretty sure a locker has called unlock, but using LockService.printLocks() still can find the locker is be holding by a thread.
> below is the log:
> 03:00:00,881 WARN [GMS] hyliuds2-8321: not member of view [hyliuds1-33648|2] [hyliuds1-33648]; discarding it
> 03:00:00,890 WARN [GMS] hyliuds2-30414: not member of view [hyliuds1-3567|4] [hyliuds1-3567, node2-9324, node2-33852]; discarding it
> 03:00:00,886 WARN [GMS] hyliuds2-13134: not member of view [hyliuds1-13050|4] [hyliuds1-13050, node2-62142, node2-26805]; discarding it
> 03:00:00,924 WARN [GMS] hyliuds2-10154: not member of view [hyliuds1-51819|4] [hyliuds1-51819, node2-14763, node2-26168]; discarding it
> 03:00:01,264 WARN [GMS] jnp://10.101.7.172:1100: not member of view [jnp://10.101.7.24:1100|2] [jnp://10.101.7.24:1100]; discarding it
> 03:00:02,368 WARN [VIEW_SYNC] discarding view as I (hyliuds2-30414) am not member of view ([hyliuds1-3567|4] [hyliuds1-3567, node2-9324, node2-33852])
> 03:00:03,659 WARN [GMS] hyliuds2-13134: failed to collect all ACKs (expected=4) for view MergeView::[node2-62142|5] [node2-62142, hyliuds2-13134, node2-26805, hyliuds1-13050], subgroups=[[hyliuds1-13050|4] [hyliuds1-13050, node2-62142, node2-26805], [hyliuds2-13134|3] [hyliuds2-13134]] after 2000ms, missing ACKs from [node2-62142, node2-26805]
> 03:00:06,019 INFO [DomainManager] Installing App sla in domain DefaultDomain.
> 03:00:06,021 INFO [DomainManager] App sla is installed in domain DefaultDomain.
> 03:00:19,321 INFO [StateCache] Accept a new Node list "[jnp://10.101.7.24:1100, jnp://10.101.7.172:1100]"
> 03:00:33,586 WARN [VIEW_SYNC] discarding view as I (hyliuds2-30414) am not member of view ([hyliuds1-3567|4] [hyliuds1-3567, node2-9324, node2-33852])
> 03:00:50,634 INFO [StateCache] Accept a new Node list "[jnp://10.101.7.24:1100, jnp://10.101.7.172:1100]"
> 03:01:03,585 WARN [VIEW_SYNC] discarding view as I (hyliuds2-30414) am not member of view ([hyliuds1-3567|4] [hyliuds1-3567, node2-9324, node2-33852])
> 03:01:30,951 INFO [DomainManager] Installing App dojoclient in domain DefaultDomain.
> 03:01:30,971 INFO [DomainManager] App dojoclient is installed in domain DefaultDomain.
> 03:01:41,450 WARN [VIEW_SYNC] discarding view as I (hyliuds2-10154) am not member of view ([hyliuds1-51819|4] [hyliuds1-51819, node2-14763, node2-26168])
> 03:01:49,799 WARN [VIEW_SYNC] discarding view as I (hyliuds2-30414) am not member of view ([hyliuds1-3567|4] [hyliuds1-3567, node2-9324, node2-33852])
> 03:02:02,298 WARN [VIEW_SYNC] discarding view as I (hyliuds2-10154) am not member of view ([hyliuds1-51819|4] [hyliuds1-51819, node2-14763, node2-26168])
> 03:03:33,370 WARN [VIEW_SYNC] discarding view as I (hyliuds2-10154) am not member of view ([hyliuds1-51819|4] [hyliuds1-51819, node2-14763, node2-26168])
> 03:04:26,623 WARN [GMS] hyliuds2-8321: not member of view [hyliuds1-33648|4] [hyliuds1-33648]; discarding it
> 03:04:35,922 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:04:35,922 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:04:37,106 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:04:53,227 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:04:53,227 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:04:53,227 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:04:53,228 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:04:53,228 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:04:53,527 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:04:54,460 INFO [DomainManager] Deploying project "/apps/sla/projects/SLAAppletProject$Deployment" with release tag "TipOfTrunk" and deployment configuration "Deployment". The overwrite flag is true. The required Runtime Server is "DefaultPool/". The required Feed Server is "auto". The required Data Source for Runtime Server is "auto". The required Data Source for Feed Server is "auto".
> 03:04:54,837 INFO [DomainManager] Project "/apps/sla/projects/SLAAppletProject$Deployment" has been dispatched with Runtime Server "DefaultPool/rs2", Feed Server "fs", Runtime Server Data Source "/vitria/m3o/datasource/DefaultDomain/datasource", Feed Server Data Source "/vitria/m3o/datasource/DefaultDomain/datasource".
> 03:04:54,986 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:04:54,987 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:04:56,972 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:05:03,650 INFO [DomainManager] Data Source "/vitria/m3o/datasource/DefaultDomain/datasource" was deployed to RuntimeServer "DefaultPool/rs2".
> 03:05:03,692 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:05:03,692 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:05:04,387 INFO [DomainManager] Data Source "/vitria/m3o/datasource/DefaultDomain/datasource" was deployed to FeedServer "fs".
> 03:05:04,956 INFO [DomainManager] Feed "/apps/sla/projects/SLAAppletProject$Deployment/Vitria/Feed/EventSourceExceptionFeed" was deployed to FeedServer "fs".
> 03:05:05,000 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:05:05,001 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:05:05,994 INFO [DomainManager] Feed "/apps/sla/projects/SLAAppletProject$Deployment/Feeds/KPINotifications" was deployed to FeedServer "fs".
> 03:05:06,991 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:05:11,047 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|5] [hyliuds2-8321]
> 03:05:13,003 INFO [DomainManager] Project "/apps/sla/projects/SLAAppletProject$Deployment" successfully deployed on server "DefaultPool/rs2".
> 03:05:13,007 INFO [DomainManager] Notify an event with type "Deploy".
> 04:57:15,746 WARN [NAKACK] hyliuds2-10154: dropped message from hyliuds1-51819 (not in table [node2-14763, node2-26168, hyliuds2-10154]), view=[node2-14763|6] [node2-14763, hyliuds2-10154, node2-26168]
> 04:57:15,785 WARN [NAKACK] hyliuds2-10154: dropped message from hyliuds1-51819 (not in table [node2-14763, node2-26168, hyliuds2-10154]), view=[node2-14763|6] [node2-14763, hyliuds2-10154, node2-26168]
> 04:57:19,956 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|7] [hyliuds2-8321]
> 04:57:35,009 WARN [NAKACK] hyliuds2-8321: dropped message from hyliuds1-33648 (not in table [hyliuds2-8321]), view=[hyliuds2-8321|7] [hyliuds2-8321]
> 04:57:43,024 ERROR [UNICAST] couldn't deliver message [dst: hyliuds2-8321, src: hyliuds1-33648 (3 headers), size=95 bytes, flags=DONT_BUNDLE]
> java.lang.NullPointerException
> at org.jgroups.protocols.Locking.handleDeleteLockRequest(Locking.java:505)
> at org.jgroups.protocols.Locking.up(Locking.java:243)
> at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:150)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:189)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:891)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:246)
> at org.jgroups.protocols.VIEW_SYNC.up(VIEW_SYNC.java:170)
> at org.jgroups.protocols.UNICAST.handleDataReceived(UNICAST.java:613)
> at org.jgroups.protocols.UNICAST.up(UNICAST.java:294)
> at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:703)
> at org.jgroups.protocols.BARRIER.up(BARRIER.java:119)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:133)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:177)
> at org.jgroups.protocols.FD.up(FD.java:275)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:275)
> at org.jgroups.protocols.MERGE2.up(MERGE2.java:209)
> at org.jgroups.protocols.Discovery.up(Discovery.java:293)
> at org.jgroups.protocols.PING.up(PING.java:69)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1109)
> at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1665)
> at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1647)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months