[JBoss JIRA] (JGRP-1660) LockService hangs during concurrent access (tryLock/tryLock(timeout)/lock/unlock)
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1660?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1660:
--------------------------------
OK, so I ran bla2 again, with 2 processes (a couple of times), and this always ran fine.
Please provide a modified bla2, which reproduces the errors and reopen this case if you can reproduce the problem.
> LockService hangs during concurrent access (tryLock/tryLock(timeout)/lock/unlock)
> ---------------------------------------------------------------------------------
>
> Key: JGRP-1660
> URL: https://issues.jboss.org/browse/JGRP-1660
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.4, 3.3.3
> Environment: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz
> 6GB RAM
> Windows 7
> JRE 1.6.31
> Reporter: Architect SoftWeb.ISD
> Assignee: Bela Ban
> Fix For: 3.3.5, 3.4, 3.5
>
> Attachments: bla2.java, lock.xml, lock.xml, LockServiceStabilityTestCase.java, LockServiceStabilityTestCase.java, LockServiceStabilityTestCase.java, lockservice_stability_testcase.jar
>
>
> We have rather simple test that starts some amount of threads which in turn simultaneously obtain lock through LockService#getLock then perform lock and unlock.
> Each thread works during some time.
> After couple of seconds of work some threads just hang up in Locking$ClientLock(Object).wait() called indirectly from LockService$LockImpl.tryLock().
> Here is stack trace:
> Thread [Thread-ClientImitation-1] (Suspended)
> Object.wait(long) line: not available [native method]
> Locking$ClientLock(Object).wait() line: 485
> Locking$ClientLock.acquireTryLock(long, boolean) line: 1010
> Locking$ClientLock.tryLock() line: 896
> CENTRAL_LOCK(Locking).down(Event) line: 152
> ProtocolStack.down(Event) line: 1025
> JChannel.down(Event) line: 718
> LockService$LockImpl.tryLock() line: 102
> LockServiceStabilityTestCase$ClientImitation.run() line: 167
> Thread.run() line: 662
--
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
10 years, 10 months
[JBoss JIRA] (JGRP-1772) Optimize marshalling and in-memory cost of strings
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1772?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1772:
--------------------------------
The code I changed would *not* benefit from {{String.intern()}} as these strings are never literals.
> Optimize marshalling and in-memory cost of strings
> --------------------------------------------------
>
> Key: JGRP-1772
> URL: https://issues.jboss.org/browse/JGRP-1772
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Currently, we use DataOutput.writeUTF() for all sorts of strings. This is implemented inefficiently and potentially uses more than 1 byte per char.
> Add another method writeString() which converts double byte chars to single byte chars so that only ASCII is supported. This can be used by a lot of internal code which never uses chars above 128.
> For external code, such as {{JChannel.connect(String cluster_name)}}, we need to see whether this is ok. Since cluster names are mainly used to differentiate clusters, perhaps it is ok to mangle the names to chars below 128, although this would change cluster names which use multi-byte chars.
--
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
10 years, 10 months
[JBoss JIRA] (JGRP-1770) Table: null row when removing last element
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1770?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1770:
---------------------------
Description:
In Table.removeMany() when nulling the last column of a row, we don't null the entire row. The effect is that we have rows (arrays) with all columns being empty remain in memory, which wastes memory.
Note that Table.purge() actually does null entire rows, this is called by
* NAKACK2: here, method stable() triggered by STABLE calls {{Table.purge(seqno)}}, so we're nulling entire rows. This is not a problem.
* UNICAST3 *sender entries*: here, reception of an ACK(seqno) also calls {{Table.purge(seqno)}}, so this is not an issue, either
The only issue is UNICAST3 *receiver entries*: here, {{Table.purge()}} is never called; elements are only nulled, but not entire rows.
SOLUTION:
When {{Table.removeMany()}} nulls an element, if that element is the last element of a row (index = {{elements_per_row -1}}, then null the entire row.
EFFECT:
There's less memory held in memory by UNICAST3 receiver entries
was:
In Table.removeMany() when nulling the last column of a row, we don't null the entire row. The effect is that we have rows (arrays) with all columns being empty remain in memory, which wastes memory.
Note that Table.purge() actually does null entire rows, this is called by
* NAKACK2: here, method stable() triggered by STABLE calls {{Table.purge(seqno)}}, so we're nulling entire rows. This is not a problem.
* UNICAST3 *sender entries*: here, reception of an ACK(seqno) also calls {{Table.purge(seqno)}}, so this is not an issue, either
The only issue is UNICAST3 *receiver entries*: here, {{Table.purge()}} is never called; elements are only nulled, but not entire rows.
SOLUTION:
When {{Table.removeMany()}} nulls an element, if that element is tha last element of a row (index = {{elements_per_row -1}}, then null the entire row.
EFFECT:
There's less memory held in memory by UNICAST3 receiver entries
> Table: null row when removing last element
> ------------------------------------------
>
> Key: JGRP-1770
> URL: https://issues.jboss.org/browse/JGRP-1770
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> In Table.removeMany() when nulling the last column of a row, we don't null the entire row. The effect is that we have rows (arrays) with all columns being empty remain in memory, which wastes memory.
> Note that Table.purge() actually does null entire rows, this is called by
> * NAKACK2: here, method stable() triggered by STABLE calls {{Table.purge(seqno)}}, so we're nulling entire rows. This is not a problem.
> * UNICAST3 *sender entries*: here, reception of an ACK(seqno) also calls {{Table.purge(seqno)}}, so this is not an issue, either
> The only issue is UNICAST3 *receiver entries*: here, {{Table.purge()}} is never called; elements are only nulled, but not entire rows.
> SOLUTION:
> When {{Table.removeMany()}} nulls an element, if that element is the last element of a row (index = {{elements_per_row -1}}, then null the entire row.
> EFFECT:
> There's less memory held in memory by UNICAST3 receiver entries
--
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
10 years, 10 months
[JBoss JIRA] (JGRP-1716) Regression between 3.2.x and 3.3.x/3.4.x in Infinispan read simulation
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1716?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1716:
---------------------------
Description:
Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput of reads in scenario simulating Infinispan went down by ~10%. See the attached chart.
* getall: the get request is sent to single node (randomly picked owner)
* getfirst: the get requests are sent to 2 nodes with ResponseMode.GET_FIRST - the second response is discarded.
h5. Suspects:
Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.
was:
Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput of reads in scenario simulating Infinispan went down by ~10%. See the attached chart.
* getall: the get request is sent to single node (randomly picked owner)
* getfirst: the get requests are sent to 2 nodes with ResponseMode.GET_FIRST - the second response is discarded.
.h5 Suspects:
Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.
> Regression between 3.2.x and 3.3.x/3.4.x in Infinispan read simulation
> ----------------------------------------------------------------------
>
> Key: JGRP-1716
> URL: https://issues.jboss.org/browse/JGRP-1716
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3, 3.4
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Labels: dm
> Fix For: 3.4.1, 3.5
>
> Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> Comparing JGroups 3.2/3.3/3.4 performance with Radargun, the throughput of reads in scenario simulating Infinispan went down by ~10%. See the attached chart.
> * getall: the get request is sent to single node (randomly picked owner)
> * getfirst: the get requests are sent to 2 nodes with ResponseMode.GET_FIRST - the second response is discarded.
> h5. Suspects:
> Erik Salter profiled his application and noticed that the message parsing in the UDP receiver thread seemed to slow things down. He wrote a patch that brought his throughput back to 3.2 levels: https://github.com/an1310/JGroups/compare/t_perfhack
> The UDP receiver thread may not tell the whole story, however: in the Radargun tests, performance with his patch was even lower.
--
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
10 years, 10 months
[JBoss JIRA] (JGRP-1761) LockServiceTest: deadlock
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1761?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1761.
----------------------------
Resolution: Done
Narrowed synchronized scope of {{ClientLockTable.unlockAll()}}.
> LockServiceTest: deadlock
> -------------------------
>
> Key: JGRP-1761
> URL: https://issues.jboss.org/browse/JGRP-1761
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> {noformat}
> Found one Java-level deadlock:
> =============================
> "Thread-157":
> waiting to lock monitor 0x00007fc2d0002a98 (object 0x00000000ceed9348, a org.jgroups.protocols.Locking$ClientLockTable),
> which is held by "pool-2-thread-10"
> "pool-2-thread-10":
> waiting to lock monitor 0x00007fc2d0002b48 (object 0x00000000cf48bc30, a org.jgroups.protocols.Locking$ClientLock),
> which is held by "Thread-157"
>
> Java stack information for the threads listed above:
> ===================================================
> "Thread-157":
> at org.jgroups.protocols.Locking$ClientLockTable.removeClientLock(Locking.java:1030)
> - waiting to lock <0x00000000ceed9348> (a org.jgroups.protocols.Locking$ClientLockTable)
> at org.jgroups.protocols.Locking$ClientLock._unlock(Locking.java:947)
> - locked <0x00000000cf48bc30> (a org.jgroups.protocols.Locking$ClientLock)
> at org.jgroups.protocols.Locking$ClientLock.unlock(Locking.java:878)
> - locked <0x00000000cf48bc30> (a org.jgroups.protocols.Locking$ClientLock)
> at org.jgroups.protocols.Locking.down(Locking.java:160)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1034)
> at org.jgroups.JChannel.down(JChannel.java:765)
> at org.jgroups.blocks.locking.LockService$LockImpl.unlock(LockService.java:161)
> at org.jgroups.blocks.LockServiceTest.unlock(LockServiceTest.java:486)
> at org.jgroups.blocks.LockServiceTest$AbstractAwaiter.run(LockServiceTest.java:366)
> at java.lang.Thread.run(Thread.java:724)
> "pool-2-thread-10":
> at org.jgroups.protocols.Locking$ClientLock.unlock(Locking.java:878)
> - waiting to lock <0x00000000cf48bc30> (a org.jgroups.protocols.Locking$ClientLock)
> at org.jgroups.protocols.Locking$ClientLockTable.unlockAll(Locking.java:1046)
> - locked <0x00000000ceed9348> (a org.jgroups.protocols.Locking$ClientLockTable)
> at org.jgroups.protocols.Locking.unlockAll(Locking.java:282)
> at org.jgroups.protocols.Locking.down(Locking.java:164)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1034)
> at org.jgroups.JChannel.down(JChannel.java:765)
> at org.jgroups.blocks.locking.LockService.unlockAll(LockService.java:65)
> at org.jgroups.blocks.LockServiceTest.unlockAll(LockServiceTest.java:57)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:653)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
>
> Found 1 deadlock.
> {noformat}
--
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
10 years, 10 months
[JBoss JIRA] (JBJCA-1140) New option for <validate-on-match/> policy
by Tom Ross (JIRA)
Tom Ross created JBJCA-1140:
-------------------------------
Summary: New option for <validate-on-match/> policy
Key: JBJCA-1140
URL: https://issues.jboss.org/browse/JBJCA-1140
Project: IronJacamar
Issue Type: Feature Request
Components: Code Generator
Environment: JBoss EAP 6.2.0
Reporter: Tom Ross
Assignee: Jesper Pedersen
There is a requirement for a new option in the pool connection validation.
<validate-on-match/> should validate, except if the connection has been returned recently into the pool for instance in the last 10 secs.
The reasoning is that if the connection has been used in the last 10 secs, and it is consider as checked. so it is not worth doing an extra validation.
The only way this could be approached at the moment would be to use more aggressively background validation. But this would put more needless pressure on the db considering all pool filled with many connections that will take time to shrink down.
With the proposed solution, would be the best of both worlds: an active application does not pay for the price of validation before use, although it uses checked connections, without having to schedule aggressive background checks.
--
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
10 years, 10 months
[JBoss JIRA] (WFLY-3027) Missing dependencies in module org.hibernate.hql
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/WFLY-3027?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero resolved WFLY-3027.
-----------------------------------
Resolution: Won't Fix
> Missing dependencies in module org.hibernate.hql
> ------------------------------------------------
>
> Key: WFLY-3027
> URL: https://issues.jboss.org/browse/WFLY-3027
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Build System, Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Davide D'Alto
> Assignee: Sanne Grinovero
>
> The module *org.hibernate.hql* doesn't have some dependencies:
> {code:xml}
> <module name="org.apache.lucene"/>
> <module name="hibernate.search.engine"/>
> <module name="org.antlr"/>
> {code}
> it also requires org.antlr:antlr-runtime and org.antlr:stringtemplate that don't exist as a module
--
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
10 years, 10 months
[JBoss JIRA] (WFLY-3027) Missing dependencies in module org.hibernate.hql
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/WFLY-3027?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero reassigned WFLY-3027:
-------------------------------------
Assignee: Sanne Grinovero
> Missing dependencies in module org.hibernate.hql
> ------------------------------------------------
>
> Key: WFLY-3027
> URL: https://issues.jboss.org/browse/WFLY-3027
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Build System, Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Davide D'Alto
> Assignee: Sanne Grinovero
>
> The module *org.hibernate.hql* doesn't have some dependencies:
> {code:xml}
> <module name="org.apache.lucene"/>
> <module name="hibernate.search.engine"/>
> <module name="org.antlr"/>
> {code}
> it also requires org.antlr:antlr-runtime and org.antlr:stringtemplate that don't exist as a module
--
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
10 years, 10 months