September 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2220) Two nodes can own a same lock at same time

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2220?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2220: -------------------------------- I don't support such an old (4 years) version. Please try this with 3.6.x or 4.x! I ran LockServiceDemo on master (4.0.7-SNAPSHOT): * Start node A * Start node B * A: {{lock X}}: lock X is acquired successfully * B: {{lock X}}: B blocks. * A: {{unlock X}}: B acquires the lock * CTRL-C A * Restart node A * A: {{lock X}}: this blocks until B calls unlock or is CTRL-C'ed Note that trylock() with a long timeout is the same as lock(). Both lock methods passed in this test > Two nodes can own a same lock at same time > ------------------------------------------ > > Key: JGRP-2220 > URL: https://issues.jboss.org/browse/JGRP-2220 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.4 > Environment: Two nodes cluster with jgroup 3.4.0 alpha2 > Reporter: Xiao Li > Assignee: Bela Ban > Fix For: 4.0.7 > > > We have a two node cluster with following protocol stack for distributed lock. > lock.protocolStack=UDP(bind_addr=myIP;bind_port=31562;mcast_addr=239.255.166.17;mcast_port=31569;ip_ttl=32;mcast_send_buf_size=150000;mcast_recv_buf_size=80000):PING(timeout=2000;num_initial_members=3):MERGE2(min_interval=5000;max_interval=10000):FD_ALL(interval=5000;timeout=20000):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(retransmit_timeout=300,600,1200,2400,4800):UNICAST(timeout=5000):pbcast.STABLE(desired_avg_gossip=20000):FRAG(frag_size=8096):pbcast.GMS(join_timeout=5000;print_local_addr=true):CENTRAL_LOCK(num_backups=2) > We use the following call to get a lock for one node. > lock = lockManager.getLock(lockId); > lock.tryLock(Long.MAX_VALUE, TimeUnit.MILLISECONDS); where lockManager is an object of LockService and lock is a Lock object. > Another node is waiting on the lock at same method call. When the node owning the lock release the lock with the call lock.unlock(), the node waiting on the lock gets the lock and the lock is deleted from the node owned the lock. When the JVM for the node that released the lock restarted, it can also get same lock. So two nodes own the lock at same time. > If I don't call lock.unlock() before shutting down the node, it waits for the lock as expected when its JVM starts up. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2217) TOA doesn't ignore DATA_MESSAGE from non-members

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/JGRP-2217?page=com.atlassian.jira.plugin.... ] Pedro Ruivo commented on JGRP-2217: ----------------------------------- can you move to the next release? I'm doing some product work this week and next :/ > TOA doesn't ignore DATA_MESSAGE from non-members > ------------------------------------------------ > > Key: JGRP-2217 > URL: https://issues.jboss.org/browse/JGRP-2217 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.6 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 4.0.7 > > > TOA accepts and handle DATA_MESSAGE from members that aren't in the view. In that case, the message stays in the queue, in the pending state, until a new view is installed and it is cleanup. > This blocks the deliver queue. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2217) TOA doesn't ignore DATA_MESSAGE from non-members

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2217?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2217: -------------------------------- Hi [~pruivo] what's the status of this issue? I have 1 issue left to tackle then I want to release a 4.0.7... > TOA doesn't ignore DATA_MESSAGE from non-members > ------------------------------------------------ > > Key: JGRP-2217 > URL: https://issues.jboss.org/browse/JGRP-2217 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.6 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 4.0.7 > > > TOA accepts and handle DATA_MESSAGE from members that aren't in the view. In that case, the message stays in the queue, in the pending state, until a new view is installed and it is cleanup. > This blocks the deliver queue. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2219) Deadlock: regression caused by ViewHandler change in 4.0.5

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2219?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2219. ---------------------------- Resolution: Done > Deadlock: regression caused by ViewHandler change in 4.0.5 > ---------------------------------------------------------- > > Key: JGRP-2219 > URL: https://issues.jboss.org/browse/JGRP-2219 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.5 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0.7 > > > Deadlock caused by https://issues.jboss.org/browse/JGRP-2031: > {noformat} > Found one Java-level deadlock: > ============================= > "jgroups-temp-thread-4253,EntityCollectionInvalidationTest-NodeF-59512": waiting for ownable synchronizer 0x0000000735645138, (a java.util.concurrent.locks.ReentrantLock$NonfairSync), which is held by "TestDisconnectHandler-1" > "TestDisconnectHandler-1": waiting to lock monitor 0x00007fdff40036f8 (object 0x00000007359182d0, a org.jgroups.protocols.pbcast.Merger), which is held by "jgroups-4,EntityCollectionInvalidationTest-NodeF-59512" > "jgroups-4,EntityCollectionInvalidationTest-NodeF-59512": waiting for ownable synchronizer 0x0000000735645138, (a java.util.concurrent.locks.ReentrantLock$NonfairSync), which is held by "TestDisconnectHandler-1"Java stack information for the threads listed above:=================================================== > "jgroups-temp-thread-4253,EntityCollectionInvalidationTest-NodeF-59512": > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x0000000735645138> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199) > at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209) > at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) > at org.jgroups.protocols.pbcast.ViewHandler.add(ViewHandler.java:92) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:841) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:233) > at org.jgroups.stack.Protocol.up(Protocol.java:302) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:591) > at org.jgroups.protocols.FD.up(FD.java:250) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:252) > at org.jgroups.protocols.MERGE3.up(MERGE3.java:276) > at org.jgroups.protocols.Discovery.up(Discovery.java:262) > at org.jgroups.protocols.TP.passMessageUp(TP.java:1229) > at org.jgroups.util.SubmitToThreadPool.lambda$loopback$0(SubmitToThreadPool.java:30) > at org.jgroups.util.SubmitToThreadPool$$Lambda$447/1407332998.run(Unknown Source) > at java.lang.Thread.run(Thread.java:748) > "TestDisconnectHandler-1": > at org.jgroups.protocols.pbcast.Merger.cancelMerge(Merger.java:431) > - waiting to lock <0x00000007359182d0> (a org.jgroups.protocols.pbcast.Merger) > at org.jgroups.protocols.pbcast.CoordGmsImpl.init(CoordGmsImpl.java:34) > at org.jgroups.protocols.pbcast.GMS.becomeCoordinator(GMS.java:407) > at org.jgroups.protocols.pbcast.ParticipantGmsImpl.handleMembershipChange(ParticipantGmsImpl.java:114) > at org.jgroups.protocols.pbcast.GMS.process(GMS.java:1296) > at org.jgroups.protocols.pbcast.GMS$$Lambda$95/1582906120.accept(Unknown Source) > at org.jgroups.protocols.pbcast.ViewHandler.process(ViewHandler.java:173) > at org.jgroups.protocols.pbcast.ViewHandler.add(ViewHandler.java:111) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:841) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:233) > at org.jgroups.stack.Protocol.up(Protocol.java:302) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:591) > at org.jgroups.stack.Protocol.up(Protocol.java:302) > at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:245) > at org.infinispan.test.hibernate.cache.util.TestDisconnectHandler.lambda$down$0(TestDisconnectHandler.java:63) > at org.infinispan.test.hibernate.cache.util.TestDisconnectHandler$$Lambda$392/1960261368.run(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > "jgroups-4,EntityCollectionInvalidationTest-NodeF-59512": > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x0000000735645138> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199) > at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209) > at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) > at org.jgroups.protocols.pbcast.ViewHandler.resume(ViewHandler.java:140) > at org.jgroups.protocols.pbcast.Merger.cancelMerge(Merger.java:435) > - locked <0x00000007359182d0> (a org.jgroups.protocols.pbcast.Merger) > at org.jgroups.protocols.pbcast.CoordGmsImpl.init(CoordGmsImpl.java:34) > at org.jgroups.protocols.pbcast.GMS.becomeCoordinator(GMS.java:407) > at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:688) > - locked <0x0000000735918798> (a org.jgroups.Membership) > - locked <0x0000000735643d68> (a org.jgroups.protocols.pbcast.GMS) > at org.jgroups.protocols.pbcast.ParticipantGmsImpl.handleViewChange(ParticipantGmsImpl.java:135) > at org.jgroups.protocols.pbcast.GMS.up(GMS.java:918) > at org.jgroups.stack.Protocol.up(Protocol.java:336) > at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:293) > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:428) > at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:962) > at org.jgroups.protocols.pbcast.NAKACK2.removeAndDeliver(NAKACK2.java:896) > at org.jgroups.protocols.pbcast.NAKACK2.handleMessages(NAKACK2.java:870) > at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:690) > at org.jgroups.protocols.FD.up(FD.java:280) > at org.jgroups.stack.Protocol.up(Protocol.java:344) > at org.jgroups.stack.Protocol.up(Protocol.java:344) > at org.jgroups.stack.Protocol.up(Protocol.java:344) > at org.jgroups.protocols.TP.passBatchUp(TP.java:1255) > at org.jgroups.util.MaxOneThreadPerSender$BatchHandlerLoop.passBatchUp(MaxOneThreadPerSender.java:284) > at org.jgroups.util.SubmitToThreadPool$BatchHandler.run(SubmitToThreadPool.java:136) > at org.jgroups.util.MaxOneThreadPerSender$BatchHandlerLoop.run(MaxOneThreadPerSender.java:273) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Found 1 deadlock. > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9383) Upgrade Narayana to 5.7.0.Final

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-9383?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed WFLY-9383. ------------------------------- Resolution: Deferred > Upgrade Narayana to 5.7.0.Final > ------------------------------- > > Key: WFLY-9383 > URL: https://issues.jboss.org/browse/WFLY-9383 > Project: WildFly > Issue Type: Component Upgrade > Components: Transactions > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9383) Upgrade Narayana to 5.7.0.Final

by Tom Jenkinson (JIRA)

Tom Jenkinson created WFLY-9383: ----------------------------------- Summary: Upgrade Narayana to 5.7.0.Final Key: WFLY-9383 URL: https://issues.jboss.org/browse/WFLY-9383 Project: WildFly Issue Type: Component Upgrade Components: Transactions Reporter: Tom Jenkinson Assignee: Tom Jenkinson -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-174) Adding link to a VM - MIQ Sprint-67

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-174?page=com.atlassian.jira.pl... ] Hayk Hovsepyan resolved HAWKULARQE-174. --------------------------------------- Resolution: Done > Adding link to a VM - MIQ Sprint-67 > ----------------------------------- > > Key: HAWKULARQE-174 > URL: https://issues.jboss.org/browse/HAWKULARQE-174 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Hayk Hovsepyan > > Enhancement - adding link to a VM also for middleware servers running in domain mode -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-174) Adding link to a VM - MIQ Sprint-67

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-174?page=com.atlassian.jira.pl... ] Hayk Hovsepyan commented on HAWKULARQE-174: ------------------------------------------- Issue is verified > Adding link to a VM - MIQ Sprint-67 > ----------------------------------- > > Key: HAWKULARQE-174 > URL: https://issues.jboss.org/browse/HAWKULARQE-174 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Hayk Hovsepyan > > Enhancement - adding link to a VM also for middleware servers running in domain mode -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6597) IJ020017: Invalid archive deploying activemq-rar

by Flavia Rainone (JIRA)

[ https://issues.jboss.org/browse/WFLY-6597?page=com.atlassian.jira.plugin.... ] Flavia Rainone reassigned WFLY-6597: ------------------------------------ Assignee: Flavia Rainone (was: Jesper Pedersen) > IJ020017: Invalid archive deploying activemq-rar > ------------------------------------------------ > > Key: WFLY-6597 > URL: https://issues.jboss.org/browse/WFLY-6597 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 10.0.0.Final > Environment: CentOS 6 > Oracle Java 1.8.0_92-b14 > Wildfly 10.0.0.Final > ActiveMQ RAR 5.13.3 > Reporter: Brett Delle Grazie > Assignee: Flavia Rainone > > Deploying ActiveMQ RAR via 'deploy' command: > deploy /opt/activemq/activemq-rar-5.13.3.rar > Results in the following log entry: > 2016-05-09 08:07:20,788 WARN [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-1) IJ020017: Invalid archive: file:/tmp/wildfly/vfs/temp/temp3cb3b15524db2617/content-d69689ded82e9101/contents/ > repeated slightly later: > 2016-05-09 08:07:20,983 WARN [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-1) IJ020017: Invalid archive: file:/tmp/wildfly/vfs/temp/temp3cb3b15524db2617/content-d69689ded82e9101/contents/ > However deployment is successful > Note that if a runtime-name is provided the RAR is *not* registered correctly. > See also previous issue raised WFLY-4431 (minimal info) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-11) [QE] - JMAN4-161 - Monitor middleware services running in OCP with OCP hosted middleware manager instance

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-11?page=com.atlassian.jira.plu... ] Hayk Hovsepyan resolved HAWKULARQE-11. -------------------------------------- Resolution: Done Labels: 4.5 mm-integration-hawkular-qe (was: 5.0 mm-integration-hawkular-qe) Back to 4.5. For 5.0 new JIRA is created: https://issues.jboss.org/browse/JMAN4-221 > [QE] - JMAN4-161 - Monitor middleware services running in OCP with OCP hosted middleware manager instance > --------------------------------------------------------------------------------------------------------- > > Key: HAWKULARQE-11 > URL: https://issues.jboss.org/browse/HAWKULARQE-11 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Labels: mm-integration-hawkular-qe, 4.5 > > See [JMAN4-161|https://issues.jboss.org/browse/JMAN4-161] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2017