July 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3441) Request to include log4j version 1.2.13 in next JBoss AS release

by Khiem Tang (JIRA)

Request to include log4j version 1.2.13 in next JBoss AS release ---------------------------------------------------------------- Key: JBAS-3441 URL: http://jira.jboss.com/jira/browse/JBAS-3441 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Logging Affects Versions: JBossAS-4.0.4.GA Environment: All OS's. Reporter: Khiem Tang Assigned To: Scott M Stark We have one component that depends on log4j-1.2.13 but the one that ships with JBoss is older. We currently use this log4j version in our JBoss stack and it seems to work fine. It would help us if JBoss put the same version (1.2.13) in the packages. -- 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: (JBREM-559) update doc for 2.0.0.CR1 release

by Tom Elrod (JIRA)

update doc for 2.0.0.CR1 release -------------------------------- Key: JBREM-559 URL: http://jira.jboss.com/jira/browse/JBREM-559 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: general Affects Versions: 2.0.0.Beta2 (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.0.0.CR1 (Boon) -- 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

18 years

2
3
0 / 0

[JBoss JIRA] Created: (JBREM-555) fix connection validator to not require extra thread to execute ping every time

by Tom Elrod (JIRA)

fix connection validator to not require extra thread to execute ping every time ------------------------------------------------------------------------------- Key: JBREM-555 URL: http://jira.jboss.com/jira/browse/JBREM-555 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: general Affects Versions: 2.0.0.Beta2 (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.0.0.CR1 (Boon) This issue is basically a better fix than was in JBREM-530. Instead of creating a new thread to make the invocation to the server and respond even when executing thread has not finished, need to create a new client invoker for the connection validator. -- 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

18 years

2
2
0 / 0

[JBoss JIRA] Created: (JBREM-553) deadlock when disconnecting

by John Mazzitelli (JIRA)

deadlock when disconnecting --------------------------- Key: JBREM-553 URL: http://jira.jboss.com/jira/browse/JBREM-553 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.Beta2 (Boon) Reporter: John Mazzitelli Assigned To: Tom Elrod Fix For: 2.0.0.CR1 (Boon) I am seeing a deadlock in my test suite. It happens everytime. I haven't finished looking at all the data, but I'm submitting this JIRA now because I only started seeing this after building a new remoting jar from HEAD and installing it. I do not believe any changes that I did caused this (I haven't changed much if any code in my own stuff - though I will test this by switching out to an older remoting jar to see what happens). Here's the two threads that deadlocked on java.util.LinkedList<E> (id=2271: Thread [Thread-3562] (Suspended) owns: java.io.BufferedInputStream (id=2299) owns: java.util.LinkedList<E> (id=2271) java.net.SocketInputStream.socketRead0(java.io.FileDescriptor, byte[], int, int, int) line: not available [native method] java.net.SocketInputStream.read(byte[], int, int) line: 129 java.io.BufferedInputStream.fill() line: 218 java.io.BufferedInputStream.read1(byte[], int, int) line: 256 java.io.BufferedInputStream.read(byte[], int, int) line: 313 java.io.ObjectInputStream$PeekInputStream.read(byte[], int, int) line: 2217 java.io.ObjectInputStream$PeekInputStream.readFully(byte[], int, int) line: 2230 java.io.ObjectInputStream$BlockDataInputStream.readShort() line: 2698 org.jboss.remoting.loading.ObjectInputStreamWithClassLoader(java.io.ObjectInputStream).readStreamHeader() line: 750 org.jboss.remoting.loading.ObjectInputStreamWithClassLoader(java.io.ObjectInputStream).<init>(java.io.InputStream) line: 268 org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.<init>(java.io.InputStream, java.lang.ClassLoader) line: 73 org.jboss.remoting.serialization.impl.java.JavaSerializationManager.createInput(java.io.InputStream, java.lang.ClassLoader) line: 52 org.jboss.remoting.transport.socket.ClientSocketWrapper.createInputStream(java.lang.String, java.net.Socket) line: 83 org.jboss.remoting.transport.socket.ClientSocketWrapper.createStreams(java.net.Socket, java.util.Map) line: 76 org.jboss.remoting.transport.socket.ClientSocketWrapper.<init>(java.net.Socket, java.util.Map, java.lang.Integer) line: 54 sun.reflect.GeneratedConstructorAccessor31.newInstance(java.lang.Object[]) line: not available sun.reflect.DelegatingConstructorAccessorImpl.newInstance(java.lang.Object[]) line: 27 java.lang.reflect.Constructor<T>.newInstance(java.lang.Object...) line: 494 org.jboss.remoting.transport.socket.SocketClientInvoker.createClientSocket(java.net.Socket, int, java.util.Map) line: 158 org.jboss.remoting.transport.socket.SocketClientInvoker(org.jboss.remoting.transport.socket.MicroSocketClientInvoker).getConnection() line: 666 org.jboss.remoting.transport.socket.SocketClientInvoker(org.jboss.remoting.transport.socket.MicroSocketClientInvoker).transport(java.lang.String, java.lang.Object, java.util.Map, org.jboss.remoting.marshal.Marshaller, org.jboss.remoting.marshal.UnMarshaller) line: 292 org.jboss.remoting.transport.socket.SocketClientInvoker(org.jboss.remoting.MicroRemoteClientInvoker).invoke(org.jboss.remoting.InvocationRequest) line: 116 org.jboss.remoting.ConnectionValidator$2.run() line: 170 java.lang.Thread.run() line: 595 Thread [main] (Suspended) owns: java.util.HashMap<K,V> (id=2272) owns: org.jboss.remoting.transport.sslsocket.SSLSocketClientInvoker (id=2273) owns: java.lang.Object (id=2274) owns: java.lang.Object (id=2275) owns: boolean[] (id=2276) waited by: Thread [JON Agent Main] (Running) waited by: Thread [JON Agent Main] (Running) waiting for: java.util.LinkedList<E> (id=2271) owned by: Thread [Thread-3562] (Running) org.jboss.remoting.transport.socket.MicroSocketClientInvoker.clearPool(org.jboss.remoting.transport.socket.ServerAddress) line: 509 org.jboss.remoting.transport.socket.MicroSocketClientInvoker.clearPools() line: 541 org.jboss.remoting.transport.sslsocket.SSLSocketClientInvoker(org.jboss.remoting.transport.socket.MicroSocketClientInvoker).handleDisconnect() line: 253 org.jboss.remoting.transport.sslsocket.SSLSocketClientInvoker(org.jboss.remoting.MicroRemoteClientInvoker).disconnect() line: 287 org.jboss.remoting.InvokerRegistry.destroyClientInvoker(org.jboss.remoting.InvokerLocator, java.util.Map) line: 225 org.jboss.remoting.Client.disconnect() line: 536 org.jboss.on.communications.command.client.JBossRemotingRemoteCommunicator.disconnect() line: 406 org.jboss.on.communications.command.client.ClientCommandSender.stopSending(boolean) line: 725 org.jboss.on.agent.AgentMain.shutdown() line: 436 org.jboss.on.agent.AgentCommTest.tearDown() line: 146 sun.reflect.GeneratedMethodAccessor26.invoke(java.lang.Object, java.lang.Object[]) line: not available sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, java.lang.Object[]) line: 25 java.lang.reflect.Method.invoke(java.lang.Object, java.lang.Object...) line: 585 org.testng.internal.MethodHelper.invokeMethod(java.lang.reflect.Method, java.lang.Object, java.lang.Object[]) line: 552 org.testng.internal.Invoker.invokeConfigurationMethod(java.lang.Object[], org.testng.ITestNGMethod, java.lang.Object[], boolean, org.testng.ITestResult) line: 318 org.testng.internal.Invoker.invokeConfigurations(org.testng.IClass, org.testng.ITestNGMethod[], org.testng.xml.XmlSuite, java.util.Map<java.lang.String,java.lang.String>, java.lang.Object) line: 152 org.testng.internal.Invoker.invokeMethod(java.lang.Object[], org.testng.ITestNGMethod, java.lang.Object[], org.testng.xml.XmlSuite, java.util.Map<java.lang.String,java.lang.String>, org.testng.ITestClass, org.testng.ITestNGMethod[], org.testng.ITestNGMethod[], org.testng.internal.ConfigurationGroupMethods) line: 483 org.testng.internal.Invoker.invokeTestMethods(org.testng.ITestNGMethod, org.testng.xml.XmlSuite, java.util.Map<java.lang.String,java.lang.String>, org.testng.ITestNGMethod[], int, org.testng.internal.ConfigurationGroupMethods) line: 778 org.testng.internal.TestMethodWorker.run() line: 105 org.testng.TestRunner.privateRun(org.testng.xml.XmlTest) line: 682 org.testng.TestRunner.run() line: 566 org.testng.SuiteRunner.privateRun() line: 220 org.testng.SuiteRunner.run() line: 146 org.testng.TestNG.createAndRunSuiteRunners(org.testng.xml.XmlSuite) line: 713 org.testng.TestNG.runSuitesLocally() line: 676 org.apache.maven.surefire.testng.TestNGExecutor.executeTestNG(org.apache.maven.surefire.suite.SurefireTestSuite, java.lang.String, org.testng.xml.XmlSuite, org.apache.maven.surefire.report.ReporterManager) line: 64 org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(org.apache.maven.surefire.report.ReporterManager, java.lang.ClassLoader) line: 75 org.apache.maven.surefire.Surefire.run(java.util.List, java.util.List, java.lang.ClassLoader, java.lang.ClassLoader) line: 129 sun.reflect.NativeMethodAccessorImpl.invoke0(java.lang.reflect.Method, java.lang.Object, java.lang.Object[]) line: not available [native method] sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object, java.lang.Object[]) line: 39 sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, java.lang.Object[]) line: 25 java.lang.reflect.Method.invoke(java.lang.Object, java.lang.Object...) line: 585 org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess() line: 225 org.apache.maven.surefire.booter.SurefireBooter.main(java.lang.String[]) line: 747 -- 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

18 years

3
9
0 / 0

[JBoss JIRA] Created: (JBREM-556) versioning tests failing

by Tom Elrod (JIRA)

versioning tests failing ------------------------ Key: JBREM-556 URL: http://jira.jboss.com/jira/browse/JBREM-556 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: general Affects Versions: 2.0.0.Beta2 (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.0.0.CR1 (Boon) Broke some backwards compatibility with previous remoting versions (1.4.x). Run versioning tests via ant target 'tests.versioning.quick' In particular, failures are: HTTP: beta2 client => rc1 server java.lang.NoClassDefFoundError: org/jboss/remoting/transport/http/WebServerError Multiplex: All failed (even rc1 client => rc1 server) RMI: beta2 client => rc1 server & rc1 client => beta2 server Caused by: java.io.InvalidClassException: org.jboss.remoting.transport.rmi.RemotingRMIClientSocketFactory; local class incompatible: stream classdesc serialVersionUID = -7491556589517716155, local class serialVersionUID = -3039839695840773968 -- 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

18 years

2
3
0 / 0

[JBoss JIRA] Created: (JBREM-548) Support one way invocations with no response

by Tim Fox (JIRA)

Support one way invocations with no response -------------------------------------------- Key: JBREM-548 URL: http://jira.jboss.com/jira/browse/JBREM-548 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Tim Fox Assigned To: Tom Elrod Fix For: 2.2.0.Beta1 (Bluto) The current remoting implementation of a client side one way invocations just performs a standard two way invocation on a different thread and returns without waiting for the result. JBoss Messaging would like to have a one way invocation which just performs a write to the underlying stream (e.g. socket outpustream) and continues without waiting for the result. This would result in less blocking and better performance since redundant writes for the invocation response would be ommitted, -- 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

18 years

3
3
0 / 0

[JBoss JIRA] Created: (JBREM-546) InvokerLocator.equals is broken

by Petr Matejka (JIRA)

InvokerLocator.equals is broken ------------------------------- Key: JBREM-546 URL: http://jira.jboss.com/jira/browse/JBREM-546 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: general Affects Versions: 1.4.4.GA Reporter: Petr Matejka Assigned To: Tom Elrod InvokerLocator.equals compares hash-codes of uris instead of comparing uris . The probability of hash collision is quite low except for cases when you connect to many nodes (which is my case, i'm connecting to >1000 nodes). -- 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

18 years

3
5
0 / 0

[JBoss JIRA] Created: (JBREM-547) need test case for exposing multiple interfaces for transporter server target pojo

by Tom Elrod (JIRA)

need test case for exposing multiple interfaces for transporter server target pojo ---------------------------------------------------------------------------------- Key: JBREM-547 URL: http://jira.jboss.com/jira/browse/JBREM-547 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: transporter Affects Versions: 2.0.0.Beta2 (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.0.0.CR1 (Boon) -- 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

18 years

2
2
0 / 0

[JBoss JIRA] Created: (JBREM-544) http client invoker (for http, https, servlet, and sslservlet) needs to handle exceptions in same manner as other transport implementations

by Tom Elrod (JIRA)

http client invoker (for http, https, servlet, and sslservlet) needs to handle exceptions in same manner as other transport implementations ------------------------------------------------------------------------------------------------------------------------------------------- Key: JBREM-544 URL: http://jira.jboss.com/jira/browse/JBREM-544 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: general Affects Versions: 2.0.0.Beta2 (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.0.0.CR1 (Boon) All the other transport clients will throw an exception from the Client.invoke() method when an error occurs. However, the http client invoker currently does not. This is a problem in that can not deliver on no api changes when changing transports. However, there is a need (by the web services group) to have the exception NOT thrown. So need to provide option for both behaviors. -- 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

18 years

2
5
0 / 0

[JBoss JIRA] Created: (JBREM-545) setting of the bind address within MulticastDetector not working

by Tom Elrod (JIRA)

setting of the bind address within MulticastDetector not working ---------------------------------------------------------------- Key: JBREM-545 URL: http://jira.jboss.com/jira/browse/JBREM-545 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: detection Affects Versions: 2.0.0.Beta2 (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.0.0.CR1 (Boon) If set the bind address within the MultiplexDetector, it does not actually bind the MultiplexSocket to that address. -- 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

18 years

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 July 2006