[JBoss JIRA] Created: (HIBERNATE-63) Blob Type get method fails on JConn2 driver for ASA
by Chris Rudd (JIRA)
Blob Type get method fails on JConn2 driver for ASA
---------------------------------------------------
Key: HIBERNATE-63
URL: http://jira.jboss.com/jira/browse/HIBERNATE-63
Project: Hibernate
Issue Type: Bug
Reporter: Chris Rudd
Assigned To: Steve Ebersole
ASAs JConn2 driver has deprectated the get/setBlob methods (throws UnsupportedOperation).
The current implementation of org.hibernate.type.BlobType (hibernate project) and org.hibernate.type.SerializableToBlobType (annotations project) consult the dialects useInputStreamToInsertBlob and will use a BinaryStream to insert the blobl data if the dialect requires it.
There is no setting / the existing setting is not used when extracting the data in the get method. It seams that ther should either be a new setting to specify that an outputstream needs to be used to extract that data, or adjust the meaning of the existing useInputStreamToInsertBlob to include read operations as well.
--
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
19 years
[JBoss JIRA] Created: (JBAOP-300) SecurityActions$PrincipalInfoAction missing from client jar
by Thomas Diesler (JIRA)
SecurityActions$PrincipalInfoAction missing from client jar
-----------------------------------------------------------
Key: JBAOP-300
URL: http://jira.jboss.com/jira/browse/JBAOP-300
Project: JBoss AOP
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Thomas Diesler
java.lang.NoClassDefFoundError: org/jboss/aspects/security/SecurityActions$PrincipalInfoAction
at org.jboss.aspects.security.SecurityActions.getPrincipal(SecurityActions.java:363)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:77)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)
--
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
19 years
[JBoss JIRA] Created: (JGRP-496) TCP: deadlock when loopback=true
by Bela Ban (JIRA)
TCP: deadlock when loopback=true
--------------------------------
Key: JGRP-496
URL: http://jira.jboss.com/jira/browse/JGRP-496
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.5
Found one Java-level deadlock:
=============================
"ConnectionTable.Connection.Receiver [10.68.28.33:7800 - 10.68.0.33:41796]":
waiting to lock monitor 0x080ca6dc (object 0xdec9a0c8, a org.jgroups.stack.NakReceiverWindow),
which is held by "Incoming Thread,perf,10.68.28.33:7800"
"Incoming Thread,perf,10.68.28.33:7800":
waiting to lock monitor 0x080ca3dc (object 0xdeb9f9e8, a java.lang.Object),
which is held by "ConnectionTable.Connection.Receiver [10.68.28.33:7800 - 10.68.0.33:41796]"
Java stack information for the threads listed above:
===================================================
"ConnectionTable.Connection.Receiver [10.68.28.33:7800 - 10.68.0.33:41796]":
at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:714)
- waiting to lock <0xdec9a0c8> (a org.jgroups.stack.NakReceiverWindow)
at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:549)
at org.jgroups.protocols.pbcast.NAKACK.handleXmitRsp(NAKACK.java:962)
at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:565)
at org.jgroups.protocols.BARRIER.up(BARRIER.java:119)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:154)
at org.jgroups.protocols.FD.up(FD.java:328)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301)
at org.jgroups.protocols.MERGE2.up(MERGE2.java:145)
at org.jgroups.protocols.Discovery.up(Discovery.java:224)
at org.jgroups.protocols.MPING.up(MPING.java:151)
at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1536)
at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1485)
at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1455)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:384)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:867)
at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1050)
at org.jgroups.protocols.TP.receive(TP.java:1021)
at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:233)
at org.jgroups.blocks.BasicConnectionTable.receive(BasicConnectionTable.java:163)
- locked <0xdeb9f9e8> (a java.lang.Object)
at org.jgroups.blocks.BasicConnectionTable$Connection.run(BasicConnectionTable.java:593)
at java.lang.Thread.run(Thread.java:595)
"Incoming Thread,perf,10.68.28.33:7800":
at org.jgroups.blocks.BasicConnectionTable.receive(BasicConnectionTable.java:163)
- waiting to lock <0xdeb9f9e8> (a java.lang.Object)
at org.jgroups.blocks.BasicConnectionTable.send(BasicConnectionTable.java:230)
at org.jgroups.protocols.TCP.send(TCP.java:54)
at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:194)
at org.jgroups.protocols.BasicTCP.sendToAllMembers(BasicTCP.java:179)
at org.jgroups.protocols.TP.doSend(TP.java:1189)
at org.jgroups.protocols.TP.send(TP.java:1179)
at org.jgroups.protocols.TP.down(TP.java:953)
at org.jgroups.protocols.Discovery.down(Discovery.java:325)
at org.jgroups.protocols.MERGE2.down(MERGE2.java:184)
at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:406)
at org.jgroups.protocols.FD.down(FD.java:363)
at org.jgroups.stack.Protocol.down(Protocol.java:252)
at org.jgroups.protocols.BARRIER.down(BARRIER.java:94)
at org.jgroups.protocols.pbcast.NAKACK.send(NAKACK.java:651)
at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:441)
at org.jgroups.protocols.pbcast.STABLE.sendStableMessage(STABLE.java:628)
at org.jgroups.protocols.pbcast.STABLE.handleRegularMessage(STABLE.java:281)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:223)
at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:723)
- locked <0xdec9a0c8> (a org.jgroups.stack.NakReceiverWindow)
at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:549)
at org.jgroups.protocols.pbcast.NAKACK.handleXmitRsp(NAKACK.java:962)
at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:565)
at org.jgroups.protocols.BARRIER.up(BARRIER.java:119)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:154)
at org.jgroups.protocols.FD.up(FD.java:328)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301)
at org.jgroups.protocols.MERGE2.up(MERGE2.java:145)
at org.jgroups.protocols.Discovery.up(Discovery.java:224)
at org.jgroups.protocols.MPING.up(MPING.java:151)
at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1536)
at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1485)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
Found 1 deadlock.
--
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
19 years
[JBoss JIRA] Created: (JBTM-213) Threads in endless loop in TransactionReaper.
by Phillip Thurmond (JIRA)
Threads in endless loop in TransactionReaper.
---------------------------------------------
Key: JBTM-213
URL: http://jira.jboss.com/jira/browse/JBTM-213
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JTA Implementation
Reporter: Phillip Thurmond
Assigned To: Mark Little
After generating a load against JBossAS 4.2 beta1, the cpu is pegged at 100% even after the load has stopped. A thread dump reveals several threads at TransactionReaper.insert(). These threads are all doing a WeakHashMap.get(). Looking at TransactionReaper, I believe this is caused by unsynchronized access to the _timeouts WeakHahsMap. This is line 324 in TransactionReaper.java.
--
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
19 years
[JBoss JIRA] Created: (JGRP-387) Reduce heavily contented locks
by Bela Ban (JIRA)
Reduce heavily contented locks
------------------------------
Key: JGRP-387
URL: http://jira.jboss.com/jira/browse/JGRP-387
Project: JGroups
Issue Type: Task
Affects Versions: 2.4
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.5
Identify and reduce/eliminate heavily contended locks, e.g.
NakReceiverWindow:
N threads will messages from the same receiver will hit the NRW (synchronization on NRW for inserts and removes). We can possibly replace the sorted hashmaps in NRW with their java.util.concurrent equivalents, so access is distributed across bucket (lock striping), reducing heavily contended locks. Also, replace ReentrantLock (e.g. used in add() and remove()) with the j.u.c.lock equivalent.
NAKACK:
Same as above: replace received_msgs with ConcurrentHashMap. Use equivalents from j.u.c.lock to replace the locks used.
Another big source of contention is that multiple threads with messsages from the *same* receiver will all add their message to the *same* NRW, then *only one* thread will remove them all and pass them up, causing the other threads to block (incurring context switches and possible processor cache flushes). When the delivery thread returns, all other threads wake up and all of them return after NRW.remove() returns null !
--
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
19 years