February 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-4013) Add ability to use multiplexer to ClusterPartition

by Brian Stansberry (JIRA)

Add ability to use multiplexer to ClusterPartition -------------------------------------------------- Key: JBAS-4013 URL: http://jira.jboss.com/jira/browse/JBAS-4013 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-4.2.0.CR1 Inject the JChannelFactoryMBean and a stack name; if present use them to construct the channel. Even if we do not deploy the multiplexer in 4.2.0, we want these hooks to leave a path for upgrading. -- 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, 11 months

1
1
0 / 0

[JBoss JIRA] Resolved: (JBAS-2731) JndiLoginInitialContextFactory still extends org.jnp.interfaces.NamingContextFactory

by Scott M Stark (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2731?page=all ] Scott M Stark resolved JBAS-2731. --------------------------------- Resolution: Done The base class has been updated. > JndiLoginInitialContextFactory still extends org.jnp.interfaces.NamingContextFactory > ------------------------------------------------------------------------------------ > > Key: JBAS-2731 > URL: http://jira.jboss.com/jira/browse/JBAS-2731 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Naming > Affects Versions: JBossAS-4.0.3 SP1 > Reporter: Arto Huusko > Assigned To: Scott M Stark > Fix For: JBossAS-4.2.0.CR1 > > > org.jboss.security.jndi.JndiLoginInitialContextFactory still extends org.jnp.interfaces.NamingContextFactory. This leads to problems with, for example, UserTransaction lookups (see JBAS-1270). > Changing the class to extend org.jboss.naming.NamingContextFactory makes it work properly. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBAS-2865) Move org.jboss.naming package from server module to naming module

by Scott M Stark (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2865?page=all ] Scott M Stark resolved JBAS-2865. --------------------------------- Resolution: Done The core jndi classes have been moved to the naming project. > Move org.jboss.naming package from server module to naming module > ----------------------------------------------------------------- > > Key: JBAS-2865 > URL: http://jira.jboss.com/jira/browse/JBAS-2865 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Naming > Reporter: Scott M Stark > Assigned To: Scott M Stark > Fix For: JBossAS-4.2.0.CR1, JBossAS-5.0.1.CR1 > > > The existence of the org.jboss.naming classes in the server module are another point for broken module dependencies. There are InitialContextFactory implementations in the security module that should subclass org.jboss.naming implementations (JBAS-2731 for example) but cannot due to server depending on security. Only naming integration services should exist in the server module. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-631) Fix org.jboss.test.remoting.transport.socket.connection.SocketConnectionCheckTestCase and SocketConnectionTestCase failures.

by Ron Sigal (JIRA)

Fix org.jboss.test.remoting.transport.socket.connection.SocketConnectionCheckTestCase and SocketConnectionTestCase failures. ----------------------------------------------------------------------------------------------------------------------------- Key: JBREM-631 URL: http://jira.jboss.com/jira/browse/JBREM-631 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Beta1 (Bluto) Reporter: Ron Sigal Assigned To: Ron Sigal Priority: Minor Fix For: 2.2.0.Beta1 (Bluto) These tests have been getting about 75% done and then failing. Looks like the System.out.println() in the loop might be causing junit to run out of heap space. -- 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, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-623) need reset() call added back to JavaSerializationManager.sendObject() method

by Tom Elrod (JIRA)

need reset() call added back to JavaSerializationManager.sendObject() method ---------------------------------------------------------------------------- Key: JBREM-623 URL: http://jira.jboss.com/jira/browse/JBREM-623 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.2.0.Alpha3 (Bluto) Reporter: Tom Elrod Assigned To: Ron Sigal Priority: Critical Fix For: 2.2.0.Beta1 (Bluto) Per JBREM-597, code was changed within JavaSerializationManager.sendObject() to not call reset() on the ObjectOutputStream as would cause an error (see below). Although this solution works, it is not optimal as need the reset() to be called to release the references kept internally to the object stream (otherwise could potentially run out of memory if are sending a lot of different object types). Error when reset() method is called: java.rmi.MarshalException: Failed to communicate. Problem during marshalling/unmarshalling; nested exception is: java.io.IOException: Can not read data for version 121. Supported versions: 1, 2 at org.jboss.remoting.transport.socket.SocketClientInvoker.handleException(SocketClientInvoker.java:122) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:408) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:125) at org.jboss.remoting.Client.invoke(Client.java:605) at org.jboss.remoting.Client.invoke(Client.java:597) at org.jboss.remoting.Client.invoke(Client.java:582) at org.jboss.test.remoting.transport.socket.connection.SocketTestClient.testInvocations(SocketTestClient.java:74) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at com.intellij.rt.execution.junit2.JUnitStarter.main(JUnitStarter.java:32) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90) Caused by: java.io.IOException: Can not read data for version 121. Supported versions: 1, 2 at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:503) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:370) ... 28 more Test case: org.jboss.test.remoting.transport.socket.connection.SocketConnectionTestCase & org.jboss.test.remoting.transport.socket.connection.SocketConnectionCheckTestCase -- 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, 11 months

2
2
0 / 0

[JBoss JIRA] Updated: (JBMESSAGING-287) RemotingTest.testConnectionListener() invalid

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-287?page=all ] Ovidiu Feodorov updated JBMESSAGING-287: ---------------------------------------- Assignee: (was: Juha Lindfors) > RemotingTest.testConnectionListener() invalid > --------------------------------------------- > > Key: JBMESSAGING-287 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-287 > Project: JBoss Messaging > Issue Type: Bug > Components: Tests and Performance > Reporter: Ovidiu Feodorov > Priority: Minor > Fix For: 1.0.3.CR1 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > I commented out that test because I wanted a clean test run for the release and also because I think the test is invalid. > After the client connects I assume there is a separate thread that renews the lease on server, so even if the main thread sleeps for 5 secs, the client renews its lease and the ConnectionListener doesn't get called. Please verify my assumption and either fix the test or remove it. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBMESSAGING-407) XARecovery integration of JBossMessaging with JBossTS

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-407?page=all ] Ovidiu Feodorov reassigned JBMESSAGING-407: ------------------------------------------- Assignee: (was: Ovidiu Feodorov) > XARecovery integration of JBossMessaging with JBossTS > ----------------------------------------------------- > > Key: JBMESSAGING-407 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-407 > Project: JBoss Messaging > Issue Type: Feature Request > Components: Tests and Performance > Environment: JBoss 4.0.3SP1, JBossTs 4.2GA, JBOSS Messagig 1.0.1CR2 > Reporter: Madhusudhan Konda > Priority: Blocker > Fix For: 1.0.2.CR1 > > Attachments: artifacts.zip, jms-recovery-patch-all.txt, jms.zip, JMSProviderXAResourceRecovery.java, xa.zip, xarecovery-patch.txt, XATestStandaloneRecovery.java > > Original Estimate: 1 week > Time Spent: 1 week, 4 hours, 30 minutes > Remaining Estimate: 0 minutes > > To make JBossMessaging XAResource as recoverable using JBossTS RecoveryManager -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBMESSAGING-407) XARecovery integration of JBossMessaging with JBossTS

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-407?page=all ] Ovidiu Feodorov reassigned JBMESSAGING-407: ------------------------------------------- Assignee: Ovidiu Feodorov (was: Juha Lindfors) > XARecovery integration of JBossMessaging with JBossTS > ----------------------------------------------------- > > Key: JBMESSAGING-407 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-407 > Project: JBoss Messaging > Issue Type: Feature Request > Components: Tests and Performance > Environment: JBoss 4.0.3SP1, JBossTs 4.2GA, JBOSS Messagig 1.0.1CR2 > Reporter: Madhusudhan Konda > Assigned To: Ovidiu Feodorov > Priority: Blocker > Fix For: 1.0.2.CR1 > > Attachments: artifacts.zip, jms-recovery-patch-all.txt, jms.zip, JMSProviderXAResourceRecovery.java, xa.zip, xarecovery-patch.txt, XATestStandaloneRecovery.java > > Original Estimate: 1 week > Time Spent: 1 week, 4 hours, 30 minutes > Remaining Estimate: 0 minutes > > To make JBossMessaging XAResource as recoverable using JBossTS RecoveryManager -- 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, 11 months

1
0
0 / 0

[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

17 years, 11 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

17 years, 11 months

2
2
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2007