February 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3845) JGCacheInvalidationBridge getPartitionName() returns incorrect value

by Brian Stansberry (JIRA)

JGCacheInvalidationBridge getPartitionName() returns incorrect value -------------------------------------------------------------------- Key: JBAS-3845 URL: http://jira.jboss.com/jira/browse/JBAS-3845 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.0.4.GA Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: JBossAS-4.0.5.SP1 Value returned is the node name not the partition name. Only use of this value is as a bit of management information (e.g. displayed in the JMX console). -- 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, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-800) CLONE -Deadlock in aop stack deployment

by Ovidiu Feodorov (JIRA)

CLONE -Deadlock in aop stack deployment --------------------------------------- Key: JBMESSAGING-800 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-800 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.0.1.GA Reporter: Ovidiu Feodorov Assigned To: Tim Fox Fix For: 1.2.0.Beta2 The following deadlock occures in TRUNK: Java stack information for the threads listed above: SERVER 1 STDOUT: =================================================== SERVER 1 STDOUT: "WorkerThread#0[127.0.0.1:54574]": SERVER 1 STDOUT: at org.jboss.aop.AspectManager.findAdvisor(AspectManager.java:518) SERVER 1 STDOUT: - waiting to lock <0x00002b1b28689000> (a java.util.WeakHashMap) SERVER 1 STDOUT: at org.jboss.aop.AspectManager.getAnyAdvisorIfAdvised(AspectManager.java:537) SERVER 1 STDOUT: at org.jboss.aop.ClassAdvisor.populateMethodTables(ClassAdvisor.java:1432) SERVER 1 STDOUT: at org.jboss.aop.ClassAdvisor.createMethodTables(ClassAdvisor.java:1448) SERVER 1 STDOUT: at org.jboss.aop.ClassAdvisor.access$100(ClassAdvisor.java:82) SERVER 1 STDOUT: at org.jboss.aop.ClassAdvisor$1.run(ClassAdvisor.java:288) SERVER 1 STDOUT: at java.security.AccessController.doPrivileged(Native Method) SERVER 1 STDOUT: at org.jboss.aop.ClassAdvisor.attachClass(ClassAdvisor.java:271) SERVER 1 STDOUT: - locked <0x00002b1b287e7da0> (a org.jboss.aop.ClassAdvisor) SERVER 1 STDOUT: at org.jboss.aop.AspectManager.initialiseClassAdvisor(AspectManager.java:587) SERVER 1 STDOUT: at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:575) SERVER 1 STDOUT: at org.jboss.jms.client.delegate.ClientConnectionDelegate.<clinit>(ClientConnectionDelegate.java) SERVER 1 STDOUT: at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint.createConnectionDelegateInternal(ServerConnectionFactoryEndpoint.java:219) SERVER 1 STDOUT: at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint.createConnectionDelegate(ServerConnectionFactoryEndpoint.java:132) SERVER 1 STDOUT: at org.jboss.jms.wireformat.ConnectionFactoryCreateConnectionDelegateRequest.serverInvoke(ConnectionFactoryCreateConnectionDelegateRequest.java:107) SERVER 1 STDOUT: at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:126) SERVER 1 STDOUT: at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:715) SERVER 1 STDOUT: at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:552) SERVER 1 STDOUT: at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:378) SERVER 1 STDOUT: at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:158) SERVER 1 STDOUT: "Thread-4": SERVER 1 STDOUT: at org.jboss.aop.Advisor.newBindingAdded(Advisor.java:516) SERVER 1 STDOUT: - waiting to lock <0x00002b1b287e7da0> (a org.jboss.aop.ClassAdvisor) SERVER 1 STDOUT: at org.jboss.aop.AspectManager.updateAdvisorsForAddedBinding(AspectManager.java:1472) SERVER 1 STDOUT: - locked <0x00002b1b28689000> (a java.util.WeakHashMap) SERVER 1 STDOUT: at org.jboss.aop.AspectManager.addBinding(AspectManager.java:1441) SERVER 1 STDOUT: - locked <0x00002b1b28689000> (a java.util.WeakHashMap) SERVER 1 STDOUT: - locked <0x00002b1b2868a3d8> (a org.jboss.aop.AspectManager) SERVER 1 STDOUT: at org.jboss.aop.AspectXmlLoader.deployBinding(AspectXmlLoader.java:286) SERVER 1 STDOUT: at org.jboss.aop.AspectXmlLoader.deployTopElements(AspectXmlLoader.java:1038) SERVER 1 STDOUT: at org.jboss.aop.AspectXmlLoader.deployXML(AspectXmlLoader.java:886) SERVER 1 STDOUT: at org.jboss.jms.client.container.JmsClientAspectXMLLoader.deployXML(JmsClientAspectXMLLoader.java:88) SERVER 1 STDOUT: at org.jboss.jms.client.ClientAOPStackLoader.load(ClientAOPStackLoader.java:69) SERVER 1 STDOUT: - locked <0x00002b1b287c7098> (a org.jboss.jms.client.ClientAOPStackLoader) SERVER 1 STDOUT: at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:199) SERVER 1 STDOUT: at org.jboss.jms.client.JBossConnectionFactory.createXAConnection(JBossConnectionFactory.java:129) SERVER 1 STDOUT: at org.jboss.jms.client.JBossConnectionFactory.createXAConnection(JBossConnectionFactory.java:124) SERVER 1 STDOUT: at org.jboss.jms.recovery.BridgeXAResourceRecovery.hasMoreResources(BridgeXAResourceRecovery.java:229) SERVER 1 STDOUT: at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecovery(XARecoveryModule.java:677) SERVER 1 STDOUT: at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:177) SERVER 1 STDOUT: at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWork(PeriodicRecovery.java:237) SERVER 1 STDOUT: at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:163) SERVER 1 STDOUT: SERVER 1 STDOUT: Found 1 deadlock. and a related one (see forum reference) in 1.0.1.gA -- 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, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-776) Specify one way thread pool on the server side too

by Tim Fox (JIRA)

Specify one way thread pool on the server side too -------------------------------------------------- Key: JBMESSAGING-776 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-776 Project: JBoss Messaging Issue Type: Task Affects Versions: 1.2.0.Beta1 Reporter: Tim Fox Fix For: 1.2.0.Beta2 We are currently not specifying metadata.put(ServerInvoker.ONEWAY_THREAD_POOL_CLASS_KEY, "org.jboss.jms.server.remoting.DirectThreadPool"); On the server side, only on the client side. Need to do this on the server side too, otherwise any one way invocations (e.g. changeRate) will unnecessarily be invoked via a thread 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

19 years, 3 months

2
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-740) Make sure wireformat is just right

by Tim Fox (JIRA)

Make sure wireformat is just right ---------------------------------- Key: JBMESSAGING-740 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-740 Project: JBoss Messaging Issue Type: Task Affects Versions: 1.2.0.Beta1 Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.0.CR1 We need to get the wireformat exactly right before the 1.2 release since changing it aftwerwards is going to give compatibility issues. We should analyse it and make sure it is exactly correct. Suggestion would be to provide a custom wire format for all invocations, not just the few we currently have so we don't rely on java/jboss serialization. Also wireformat for ping -- 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, 3 months

2
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-721) Message redelivery doesn't work

by Amit Bhayani (JIRA)

Message redelivery doesn't work -------------------------------- Key: JBMESSAGING-721 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-721 Project: JBoss Messaging Issue Type: Bug Components: Messaging Core Affects Versions: 1.0.1.SP2 Reporter: Amit Bhayani Assigned To: Ovidiu Feodorov Priority: Critical Fix For: 1.0.2.CR1 Attachments: mdb.zip Message redelivery in CMT MDB is not working. I set the transaction to setRollbackOnly on MessageDrivenContext within onMessage of MDB and ideally the message should get redelivered. I can see that Message reamins in the queue for long time. No error message is shown in server.log file. I have created a simple testcase (attached here). Sender.java send's 6 messages. Messages 1,2,3,4 and 5 are consumed however for message 6 MDBExample.java sets the setRollbackOnly after this there is no activity and message 6 remains in the queue. This testcase is from jboss-messaging-1.0.1.SP2-src\docs\examples\mdb. Just replace the files to test. -- 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, 3 months

4
13
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-638) Potential memory leak when using 2pc via JCA adapter.

by Tim Fox (JIRA)

Potential memory leak when using 2pc via JCA adapter. ----------------------------------------------------- Key: JBMESSAGING-638 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-638 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.0.1.GA Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.0.2.CR1 Martin Welss has reported a potential memory leak when using 2pc via the JCA adaptor. It seems that client side TxState instances remain in the resource manager. Need to investigate further. -- 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, 3 months

2
11
0 / 0

[JBoss JIRA] Assigned: (JBAS-1437) RAR MetaData Repository

by Weston Price (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1437?page=all ] Weston Price reassigned JBAS-1437: ---------------------------------- Assignee: Weston Price > RAR MetaData Repository > ----------------------- > > Key: JBAS-1437 > URL: http://jira.jboss.com/jira/browse/JBAS-1437 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JCA service > Reporter: Adrian Brock > Assigned To: Weston Price > Priority: Minor > > Forums Discussion Thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=48681 > Implement a RAR MetaData repository. > There are two use cases of this object: > * A tool wants to retrieve information about how to configure a RAR deployment > either inbound/outbound or admin object > * Avoiding the need to specify the rar-name in jboss.xml, -ds.xml or admin object deployments when > only one rar implements the connection definition or message listener. > Design: > 1) When a RAR is deployed/undeployed update the repository with information about the RAR including > cross references by > * ConnectionDefinition > * MessageListener > * AdminObject > 2) When an MDB is deployed without identifying the rar, use the repository to try to guess the RAR > 3) When a ConnectionFactory is deployed without identifying the rar, use the repository to try to guess the RAR > 4) When an AdminObject is deployed without identifying the rar, use the repository to try to guess the RAR > The algorithm to guess the RAR is > a) Is there only one RAR implementing the object > b) If there is more than one RAR, is there a specific RAR in the same top level deployment (EAR) > as the referencing deployment -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-963) Eviction thread timer is not a daemon

by Brian Stansberry (JIRA)

Eviction thread timer is not a daemon ------------------------------------- Key: JBCACHE-963 URL: http://jira.jboss.com/jira/browse/JBCACHE-963 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.ALPHA2, 1.4.1.GA, 1.4.0.SP1, 1.4.0.GA, 1.3.0.SP4, 1.3.0.GA, 1.2.4SP2, 1.2.4, 1.4.1.SP1 Reporter: Brian Stansberry Assigned To: Manik Surtani Fix For: 2.0.0.BETA2 The Timer used for the eviction thread needs to have true passed to it's constructor, otherwise it prevents shutdown of the application if stopService() is not invoked. -- 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, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-773) isLocalInterceptor will invoke local bean when the proxy is remote

by William DeCoste (JIRA)

isLocalInterceptor will invoke local bean when the proxy is remote ------------------------------------------------------------------ Key: EJBTHREE-773 URL: http://jira.jboss.com/jira/browse/EJBTHREE-773 Project: EJB 3.0 Issue Type: Bug Reporter: William DeCoste Assigned To: William DeCoste IsLocalInterceptor checks to see if the container is local based on the OID (e.g. jboss.j2ee:jar=stateless-test.jar,name=CheckedStatelessBean,service=EJB3) via Ejb3Registry.getContainer(oid.toString()). If the bean is deployed identically to the local and remote server and the proxy is remote, the call will still be handled locally. Checking the Ejb3Registry doesn't work in this case. -- 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, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-965) Inadvertent dependency on JGroups 2.2.9

by Manik Surtani (JIRA)

Inadvertent dependency on JGroups 2.2.9 --------------------------------------- Key: JBCACHE-965 URL: http://jira.jboss.com/jira/browse/JBCACHE-965 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.1.GA Reporter: Manik Surtani Assigned To: Manik Surtani Priority: Minor Fix For: 1.4.1.SP1 A lousy log statement was using JBCMethodCall.getId() which introduced a dep on JG 2.2.9. -- 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, 3 months

1
1
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 February 2007