[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
17 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
17 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
17 years
[JBoss JIRA] Created: (JGRP-457) Optimization: make threads return immediately if NAKACK has another active thread for the same sender
by Bela Ban (JIRA)
Optimization: make threads return immediately if NAKACK has another active thread for the same sender
-----------------------------------------------------------------------------------------------------
Key: JGRP-457
URL: http://jira.jboss.com/jira/browse/JGRP-457
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Priority: Minor
Fix For: 2.5
In NAKACK, when a thread places a message for sender S into the NakReceiverWindow NRW, it subsequently acquires a lock on NRW (lock by sender) and removes as many messages as possible and passes them up.
If many threads do this at the same time, all threads but one are blocked, and - when finally unblocked - usually return. This causes context switches and possibly cache flushing, so a better way would be to have the threads check whether another thread is already removing messages using a CAS operation *before* acquiring the lock.
The effect should be that no threads will wait on the lock unnecessarily, and thus fewer context switches, and more threads available to the pool.
--
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
17 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
17 years
[JBoss JIRA] Created: (JBAS-4155) run.conf used from other scripts than run.sh
by Tobias Frech (JIRA)
run.conf used from other scripts than run.sh
--------------------------------------------
Key: JBAS-4155
URL: http://jira.jboss.com/jira/browse/JBAS-4155
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Other
Affects Versions: JBossAS-4.0.5.GA
Environment: Linux/Unix
Reporter: Tobias Frech
Priority: Minor
Configuration in run.conf is used from other scripts than run.sh. For example shutdown.sh or twiddle.sh include it. They should not because that leads to undesireable or even dangeous effects.
Details:
Editing run.conf an including
JAVA_OPTS="$JAVA_OPTS -Xdebug -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=y"
to enable remote debugging
Starting the server:
sh run.sh -c minimal
Stopping the server produces:
sh shutdown.sh -S
ERROR: transport error 202: bind failed: Address already in use ["transport.c",L41]
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510) ["debugInit.c",L497]
JDWP exit error JVMTI_ERROR_INTERNAL(113): No transports initializedFATAL ERROR in native method: JDWP No transports initialized, jvmtiError=JVMTI_ERROR_INTERNAL(113)
This may get worse if someone uses a -Xms3000m setting on a server that only has 4GB of memory. Potentially leading to a swap out of a production system to disk.
--
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
17 years
[JBoss JIRA] Commented: (JBMESSAGING-353) ConnectionConsumerTest.testRedeliveryTransacted() fails on Mac OSX 10.4.6 but passes on Windows
by Aaron Walker (JIRA)
[ http://jira.jboss.com/jira/browse/JBMESSAGING-353?page=comments#action_12... ]
Aaron Walker commented on JBMESSAGING-353:
------------------------------------------
I tested this on my intel iMac and the test now passes with the following setup
Java Version 1.5.0_07
Java Vendor Apple Computer, Inc.
Java VM Name Java HotSpot(TM) Client VM
Java VM Version 1.5.0_07-87
Java VM Info mixed mode, sharing
OS Name Mac OS X
OS Version 10.4.9
OS Arch i386
I tested this against the Branch_1_2_0_SP branch.
I don't have my old powerbook with me right now but I suspect it will also pass.
Should all the test pass on the Branch_1_2_0_SP branch ?????
> ConnectionConsumerTest.testRedeliveryTransacted() fails on Mac OSX 10.4.6 but passes on Windows
> -----------------------------------------------------------------------------------------------
>
> Key: JBMESSAGING-353
> URL: http://jira.jboss.com/jira/browse/JBMESSAGING-353
> Project: JBoss Messaging
> Issue Type: Bug
> Components: JMS Facade, Tests and Performance
> Affects Versions: 1.0.0, 1.0.1.CR1
> Environment: mac osx 10.4.6
> JDK 1.4.2_09
> JDK 1.5.0_04
> Reporter: Aaron Walker
> Assigned To: Aaron Walker
> Fix For: 2.0.0 Beta 1
>
> Attachments: messaging-tests.trace.log
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> The testRedeliveryTransacted fail with the following:
> 1) testRedeliveryTransacted(org.jboss.test.messaging.jms.ConnectionConsumerTest)junit.framework.AssertionFailedError: Didn't receive correct messages
> at org.jboss.test.messaging.jms.ConnectionConsumerTest.testRedeliveryTransacted(ConnectionConsumerTest.java:224)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at org.jboss.test.messaging.tools.junit.SelectiveTestRunner.main(SelectiveTestRunner.java:58)
> The issue revolves around the sess.rollback around line 433 in that after the rollback and the 3 messages get redelivered and on the 3rd message the following if (!tm.getJMSRedelivered()) at line 481 evaluates to true in that the getJMSRedelivered() is false when it should be true. By placing a 1ms sleep just prior to the rollback you can get the test to pass. So after my initial investigation It appears that it may be some sort of threading issue that shows up on my mac.
> I will attached the TRACE log for this If you look at line 765 of the log it shows that the delivery count for the message is 0 when it should be 1
--
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
17 years