July 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBBUILD-421) Classpath is incorrect when running javadoc reports

by Paul Gier (JIRA)

Classpath is incorrect when running javadoc reports --------------------------------------------------- Key: JBBUILD-421 URL: http://jira.jboss.com/jira/browse/JBBUILD-421 Project: JBoss Build System Issue Type: Bug Components: Maven Reporter: Paul Gier Fix For: Maven Build - Maint 2007 JBoss Cache build has an issue with the javadoc plugin. The javadocs work fine when run from the main build, but fail with errors when generating the site. It appears that the testng jar is required for the javadoc generation, but this jar is not getting included in the classpath when run from the reports section. The issue could be related to this one: http://jira.codehaus.org/browse/MJAVADOC-140 -- 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

15 years, 7 months

1
4
0 / 0

[JBoss JIRA] Created: (JBBUILD-442) Fix pom.xmls so that maven-eclipse-plugin generate correct eclipse settings files

by pether (JIRA)

Fix pom.xmls so that maven-eclipse-plugin generate correct eclipse settings files --------------------------------------------------------------------------------- Key: JBBUILD-442 URL: http://jira.jboss.com/jira/browse/JBBUILD-442 Project: JBoss Build System Issue Type: Feature Request Components: Maven Affects Versions: Maven Build - Maint 2008 Reporter: pether Priority: Minor Fix For: Maven Build - Maint 2008 Two different cases that should work for developers to choose from 1. Using eclipse project references generate files with : mvn eclipse:clean eclipse:eclipse -Declipse.useProjectReferences=true 2. Using maven repository jar references generate files with : mvn eclipse:clean eclipse:eclipse -Declipse.useProjectReferences=true In some ways an audit of http://jira.jboss.org/jira/browse/JBBUILD-258 and resolve any issues with dependencies. Current issues with jboss/trunk The projects below have compile errors, mostly incorrect project dependencies jboss-as-deployment jboss-as-console jboss-as-iiop jboss-as-varia -- 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

15 years, 7 months

2
13
0 / 0

[JBoss JIRA] Created: (JBBUILD-469) Create a bouncycastle dist without IDEA code

by Scott M Stark (JIRA)

Create a bouncycastle dist without IDEA code -------------------------------------------- Key: JBBUILD-469 URL: http://jira.jboss.com/jira/browse/JBBUILD-469 Project: JBoss Build System Issue Type: Feature Request Reporter: Scott M Stark Assigned To: Scott M Stark Create a dist from the http://www.bouncycastle.org/ code that does not include the patent encumbered IDEA algorithms. -- 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

15 years, 7 months

3
3
0 / 0

[JBoss JIRA] Created: (JGRP-685) Perf test

by Bela Ban (JIRA)

Perf test --------- Key: JGRP-685 URL: http://jira.jboss.com/jira/browse/JGRP-685 Project: JGroups Issue Type: Task Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.7 Things to do with the perf test: - Mimick buddy replication: send messages not to self, but only to a selected buddy - Measure time to send 100MB to A, B, C, D - New look at HTOTAL, might help with perf in this scenario - TcpTransport (95MB/sec) versus JGroupsTransport/tcp.xml (54MB/sec): why the diff ? - Members: A (send), B (receive) - Might get better perf with impl of first bullet item (above) - JPerf (between A and B) gets 113MB/sec ! -- 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

15 years, 7 months

1
12
0 / 0

[JBoss JIRA] Created: (JGRP-1003) deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send()

by Victor N (JIRA)

deadlock in TP.send - socket write hangs inside a Lock, preventing other threads to do TP.send() ------------------------------------------------------------------------------------------------ Key: JGRP-1003 URL: https://jira.jboss.org/jira/browse/JGRP-1003 Project: JGroups Issue Type: Bug Affects Versions: 2.7 Environment: Linux (Debian), kernel 2.6.x Reporter: Victor N Assignee: Bela Ban I am using JGroups 2.7.0 GA with the typical protocols stack based on TCP (taken from tcp.xml). Sometimes it occurs that socket write operation hangs inside TP.send() -- this is not so untypical for blocking I/O approach! -- after that JGroups is not working at all because most of threads are blocked inside TP.send() waiting for that first thread releasing "out_stream_lock". Below is a fragment from my stack trace. 1) the thread that hangs in socket write until forever (maybe due to a broken socket or something else); this thread owns "out_stream_lock in TP class": "Timer-1,name,IP:port" daemon prio=10 tid=0x084e5c00 nid=0x15f0 runnable [0x211c1000..0x211c2040] java.lang.Thread.State: RUNNABLE at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123) - locked <0x43427300> (a java.io.BufferedOutputStream) at java.io.DataOutputStream.flush(DataOutputStream.java:106) at org.jgroups.blocks.TCPConnectionMap$TCPConnection.doSend(TCPConnectionMap.java:472) at org.jgroups.blocks.TCPConnectionMap$TCPConnection._send(TCPConnectionMap.java:453) at org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(TCPConnectionMap.java:436) at org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap.java:341) at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:137) at org.jgroups.protocols.TCP.send(TCP.java:53) at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:141) at org.jgroups.protocols.TP.doSend(TP.java:1105) at org.jgroups.protocols.TP.send(TP.java:1088) at org.jgroups.protocols.TP.down(TP.java:907) at org.jgroups.protocols.Discovery.down(Discovery.java:363) at org.jgroups.protocols.MERGE2.down(MERGE2.java:169) at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:333) at org.jgroups.protocols.FD.down(FD.java:327) at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:72) at org.jgroups.protocols.BARRIER.down(BARRIER.java:96) at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1530) at org.jgroups.protocols.pbcast.NAKACK.retransmit(NAKACK.java:1476) at org.jgroups.stack.Retransmitter$Task.run(Retransmitter.java:207) at org.jgroups.util.TimeScheduler$TaskWrapper.run(TimeScheduler.java:218) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Locked ownable synchronizers: - <0x2b5522e0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) - <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) - <0x434273f0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) 2) and there are many threads like this blocked "on out_stream_lock.lock()" call inside TP class: "Connection.Receiver [ip:port - ip:port],name,ip:port" prio=10 tid=0x020dc000 nid=0x1fab waiting on condition [0x1365f000..0x1365ffc0] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x2b5550f8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114) at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186) at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262) at org.jgroups.protocols.TP.send(TP.java:1082) at org.jgroups.protocols.TP.down(TP.java:907) at org.jgroups.protocols.Discovery.up(Discovery.java:274) at org.jgroups.protocols.TP.passMessageUp(TP.java:995) at org.jgroups.protocols.TP.access$100(TP.java:52) at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1451) at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1427) at java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(ThreadPoolExecutor.java:1738) at org.jgroups.util.ShutdownRejectedExecutionHandler.rejectedExecution(ShutdownRejectedExecutionHandler.java:34) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658) at org.jgroups.protocols.TP.dispatchToThreadPool(TP.java:1061) at org.jgroups.protocols.TP.receive(TP.java:1038) at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:180) at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:553) at java.lang.Thread.run(Thread.java:619) Locked ownable synchronizers: - None (Since all threads from JGroups' ThreadPool are locked, you can see "rejectedExecution" in the last stack trace). Maybe we could implement some solution for TCP (blocking I/O)? Maybe it is possible to release the lock before socket write? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

2
41
0 / 0

[JBoss JIRA] Created: (JBAS-6348) Problem with QueuedPessimisticEJBLock and Arjuna

by Ole Husgaard (JIRA)

Problem with QueuedPessimisticEJBLock and Arjuna ------------------------------------------------ Key: JBAS-6348 URL: https://jira.jboss.org/jira/browse/JBAS-6348 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Transaction Manager (Arjuna) Affects Versions: JBossAS-4.2.3.GA Reporter: Ole Husgaard Assignee: Jonathan Halliday When using Arjuna, QueuedPessimisticEJBLock does not always properly detect that a waiting tx has timed out. The problem is that QueuedPessimisticEJBLock was written for the old TM, which did not rollback transactions on timeout, but only marked them for rollback. Now that Arjuna is in play, it has to check for rolled back transactions too. The isTxExpired() method should be changed to something like this: protected boolean isTxExpired(Transaction miTx) throws Exception { if (miTx != null && (miTx.getStatus() == Status.STATUS_MARKED_ROLLBACK || miTx.getStatus() == Status.STATUS_ROLLEDBACK)) { return true; } return false; } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

5
7
0 / 0

[JBoss JIRA] Created: (JBAS-6244) document how to properly configure resource recovery in jbossjta-properties.xml

by John Mazzitelli (JIRA)

document how to properly configure resource recovery in jbossjta-properties.xml ------------------------------------------------------------------------------- Key: JBAS-6244 URL: https://jira.jboss.org/jira/browse/JBAS-6244 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Docs/Administration and Configuration Guide Affects Versions: JBossAS-4.2.1.GA Reporter: John Mazzitelli Assignee: Samson Kittoli Currently, people are having a tough time figuring out how to correct this error when their apps hit it while running inside of JBossAS: 21:31:10,147 WARN oggerI18N om.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa om.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa Could not find new XAResource to use for recovering non-serializable XAResource For examples of the types of questions people are asking (yes, I was one of them :): http://www.jboss.com/index.html?module=bb&op=viewtopic&t=146138&start=0&p... http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=78... http://www.nabble.com/JBoss-Integration---recovering-XAResource-td2003557... http://forums.java.net/jive/thread.jspa?messageID=254647 This talks about the problem, but nothing specifically addresses how to actually fix the problem: http://www.jboss.org/community/docs/DOC-12463 This comes close - but it mentions Messaging specific things, so it is not clear how you do this for your own JDBC data sources: https://www.jboss.org/community/docs/DOC-12826 This JIRA is to request that our documentation specifically address this problem and provide explicit hints as to how to fix it. Mention things like: 1) the existance of the Oracle and generic JNDI recovery modules, but how they are not configured/activated out-of-box 2) how to edit jbossjta-properties.xml to configure those modules with the JDBC URL/JNDI URI and db user/pass 3) how to add the recovery modules in jbossjta-properties.xml I talk about how I plan to solve this in that first forum post linked above - that could be used as an example for the kind of docs I was looking for. Even if all this JIRA does is add a commented section in jbossjta-properties.xml, that would go a long way in helping solve this problem for people without them resulting to hair pulling or jumping off bridges. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

9
20
0 / 0

[JBoss JIRA] Created: (JBAS-6732) Add a section on configuring logging

by Jason T. Greene (JIRA)

Add a section on configuring logging ------------------------------------ Key: JBAS-6732 URL: https://jira.jboss.org/jira/browse/JBAS-6732 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Jason T. Greene Assignee: David Lloyd -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

4
11
0 / 0

[JBoss JIRA] Created: (JBAOP-721) Binds with similar pointcut expressions are ignored

by Carlo de Wolf (JIRA)

Binds with similar pointcut expressions are ignored --------------------------------------------------- Key: JBAOP-721 URL: https://jira.jboss.org/jira/browse/JBAOP-721 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.1.0.GA Environment: Branch_5_x @ 87425 Reporter: Carlo de Wolf Priority: Critical Fix For: 2.1.1.GA, 2.2.0.GA Given the following descriptor: http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/ejb3/trunk/co... 04-16-2009 09:47:58: ERROR: java.lang.NullPointerException at org.jboss.ejb3.entity.ExtendedPersistenceContextPropagationInterceptor.invoke(ExtendedPersistenceContextPropagationInterceptor.java:57) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.security.RunAsSecurityInterceptorv2.invoke(RunAsSecurityInterceptorv2.java:94) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:201) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:186) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66) at org.jboss.ejb3.tx.TxInterceptor$Never.invoke(TxInterceptor.java:63) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.stateful.StatefulContainer.dynamicInvoke(StatefulContainer.java:560) at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53) at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91) StatefulInstanceInterceptor is not executed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

3
18
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1781) Finalize a contract between no-interface and InvokableContext

by jaikiran pai (JIRA)

Finalize a contract between no-interface and InvokableContext -------------------------------------------------------------- Key: EJBTHREE-1781 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1781 Project: EJB 3.0 Issue Type: Task Components: proxy Reporter: jaikiran pai Assignee: jaikiran pai As part of the fix for EJBTHREE-1777, the SessionProxy has now been removed. The no-interface was responsible for passing this to the InvokableContext for invoking on the context. We need to decide on the new contract. Since the InvokableContext just needs a target (=sessionId), the no-interface can pass this information to the InvokableContext. Need to see how this fits in with the proxy-impl which too relies on the InvokableContext. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

2
3
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 July 2009