May 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBREM-873) Have ServerInvokerCallbackHandler register as connection listener

by Ron Sigal (JIRA)

Have ServerInvokerCallbackHandler register as connection listener ----------------------------------------------------------------- Key: JBREM-873 URL: http://jira.jboss.com/jira/browse/JBREM-873 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.2.0.SP2, 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.2.SP4 This feature is implemented in response to JBPAPP-402 :"In certain situations createQueueConnection can hang". JBossMessaging does not, in general, call org.jboss.remoting.callback.ServerInvokerCallbackHandler.destroy() when a lease indicates that a connection has failed. More generally, the need to call ServerCallbackHandler.destroy() is not documented in the Remoting Guide, so it is possible that JBossMessaging is not alone. -- 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 months

1
8
0 / 0

[JBoss JIRA] Created: (JBREM-871) HTTP Client invoker doesn't throw exceptions when using the sslservlet protocol

by Jay Howell (JIRA)

HTTP Client invoker doesn't throw exceptions when using the sslservlet protocol ------------------------------------------------------------------------------- Key: JBREM-871 URL: http://jira.jboss.com/jira/browse/JBREM-871 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.2.2.GA_CP01 Reporter: Jay Howell In the HTTP Client Invoker, the only server side exceptions that get thrown are for the servlet protocol only... and also have to be servlet exceptions... The code from the client that throws the exception is inside of this if block.... i// now check for error response and throw exception unless configured to not do so if(responseCode >= 400 || ("servlet".equals(getLocator().getProtocol()) && result instanceof InvocationResponse && ((InvocationResponse) result).getResult() instanceof ServletThrowable)) { -- 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 months

2
10
0 / 0

[JBoss JIRA] Created: (JBREM-858) MaxPoolSize value should be used in key to MicroSocketClientInvoker.connectionPools

by Ron Sigal (JIRA)

MaxPoolSize value should be used in key to MicroSocketClientInvoker.connectionPools ----------------------------------------------------------------------------------- Key: JBREM-858 URL: http://jira.jboss.com/jira/browse/JBREM-858 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP2, 2.2.2.GA_CP01, 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.2.GA_CP03 If two instances of org.jboss.remoting.Client are created, one with clientMaxPoolSize=1 and one with clientMaxPoolSize=30, they will still share the same connection pool because the key to the connection pools, org.jboss.remoting.transport.socket.ServerAddress, does not include the value of clientMaxPoolSize. ServerAddress.equals() and ServerAddress.hashCode() should be modified to include the value of clientMaxPoolSize. -- 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 months

1
15
0 / 0

[JBoss JIRA] Created: (JBREM-860) Eliminate delay in MicroSocketClientInvoker.getConnection()

by Ron Sigal (JIRA)

Eliminate delay in MicroSocketClientInvoker.getConnection() ----------------------------------------------------------- Key: JBREM-860 URL: http://jira.jboss.com/jira/browse/JBREM-860 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP2, 2.2.2.GA_CP01, 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.2.GA_CP03, 2.4.0.Beta1 (Pinto) org.jboss.remoting.transport.socket.MicroSocketClientInvoker.getConnection() currently calls Thread.sleep(1000) after each unsuccessful attempt to retrieve a connection from the connection pool. This introduced an unnecessary delay in general, and, in particular, makes the use of a connection pool of size one impractical. -- 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 months

2
14
0 / 0

[JBoss JIRA] Created: (JBREM-855) Update build.xml to allow jdk 1.5 compiler to target JVM version 1.4

by Ron Sigal (JIRA)

Update build.xml to allow jdk 1.5 compiler to target JVM version 1.4 -------------------------------------------------------------------- Key: JBREM-855 URL: http://jira.jboss.com/jira/browse/JBREM-855 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.2.2.GA_CP01, 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Priority: Minor Fix For: 2.2.2.GA_CP02, 2.4.0.Beta1 (Pinto) Fernando has suggested updating build.xml so that the *-brew scripts can use the jdk 1.5 compiler to generate code that is compatible with a 1.4 JVM. This way we have a single version of jboss-remoting.jar in the repository which is (1) appropriate in the current versions of the Application Server, which are compiled with jdk 1.5, and (2) usable in a standalone context by clients built with a jdk 1.4 compiler. The changes should be applied to the following branches: - remoting_2_2_0_GA (for community AS) - remoting_2_2_2_GA_CP (for EAP 4.2 and 4.3) - remoting_2_x (for Remoting 2.4.0) -- 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 months

1
16
0 / 0

[JBoss JIRA] Created: (JBREM-852) Verify IPv6 addresses are handled correctly

by Ron Sigal (JIRA)

Verify IPv6 addresses are handled correctly ------------------------------------------- Key: JBREM-852 URL: http://jira.jboss.com/jira/browse/JBREM-852 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP2, 2.2.2.GA_CP01, 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) Need to make sure that Remoting can bind ServerSockets to IPv6 addresses. This issue is related to http://jira.jboss.com/jira/browse/JBREM-645. -- 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 months

1
14
0 / 0

[JBoss JIRA] Created: (JBREM-845) Infinite loop in BisocketClientInvoker.createSocket

by Carlo de Wolf (JIRA)

Infinite loop in BisocketClientInvoker.createSocket --------------------------------------------------- Key: JBREM-845 URL: http://jira.jboss.com/jira/browse/JBREM-845 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP2, 2.2.2.GA_CP01 Reporter: Carlo de Wolf Priority: Blocker The following piece of code constitutes an infinite loop when timeout = 0: while (timeout == 0 || wait > 0) { try { sockets.wait(wait); break; } catch (InterruptedException e) { log.debug("unexpected interrupt"); if (timeout > 0) wait = timeout - (System.currentTimeMillis() - start); } } "Thread-41" prio=1 tid=0x00002aaaac3cd0b0 nid=0x2e87 in Object.wait() [0x0000000048fe3000..0x0000000048fe3d80] at java.lang.Object.wait(Native Method) - waiting on <0x00002b7156e2f410> (a java.util.HashSet) at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.createSocket(BisocketClientInvoker.java:458) - locked <0x00002b7156e2f410> (a java.util.HashSet) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.getConnection(MicroSocketClientInvoker.java:815) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:525) at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:413) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122) at org.jboss.remoting.Client.invoke(Client.java:1634) at org.jboss.remoting.Client.invoke(Client.java:548) at org.jboss.remoting.Client.invokeOneway(Client.java:598) at org.jboss.remoting.callback.ServerInvokerCallbackHandler.handleCallback(ServerInvokerCallbackHandler.java:815) at org.jboss.remoting.callback.ServerInvokerCallbackHandler.handleCallbackOneway(ServerInvokerCallbackHandler.java:686) at org.jboss.jms.server.endpoint.ServerSessionEndpoint.performDelivery(ServerSessionEndpoint.java:1490) - locked <0x00002b71569e25e8> (a org.jboss.remoting.transport.bisocket.BisocketClientInvoker) at org.jboss.jms.server.endpoint.ServerSessionEndpoint.handleDelivery(ServerSessionEndpoint.java:1375) - locked <0x00002b71569dfd40> (a org.jboss.jms.server.endpoint.ServerSessionEndpoint) at org.jboss.jms.server.endpoint.ServerConsumerEndpoint.handle(ServerConsumerEndpoint.java:307) - locked <0x00002b71569ed6b0> (a java.lang.Object) at org.jboss.messaging.core.impl.RoundRobinDistributor.handle(RoundRobinDistributor.java:119) at org.jboss.messaging.core.impl.MessagingQueue$DistributorWrapper.handle(MessagingQueue.java:582) at org.jboss.messaging.core.impl.ClusterRoundRobinDistributor.handle(ClusterRoundRobinDistributor.java:79) at org.jboss.messaging.core.impl.ChannelSupport.deliverInternal(ChannelSupport.java:476) at org.jboss.messaging.core.impl.MessagingQueue.deliverInternal(MessagingQueue.java:505) at org.jboss.messaging.core.impl.ChannelSupport.deliver(ChannelSupport.java:226) - locked <0x00002b71565d3d50> (a java.lang.Object) at org.jboss.jms.server.endpoint.ServerSessionEndpoint$2.run(ServerSessionEndpoint.java:1598) at EDU.oswego.cs.dl.util.concurrent.QueuedExecutor$RunLoop.run(QueuedExecutor.java:89) at java.lang.Thread.run(Thread.java:595) -- 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 months

3
26
0 / 0

[JBoss JIRA] Created: (JBREM-823) ServerInvoker#getMBeanObjectName() returns invalid ObjectName if host value is IPv6

by Takayoshi Kimura (JIRA)

ServerInvoker#getMBeanObjectName() returns invalid ObjectName if host value is IPv6 ----------------------------------------------------------------------------------- Key: JBREM-823 URL: http://jira.jboss.com/jira/browse/JBREM-823 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.0.0.Alpha1 (Otter) Reporter: Takayoshi Kimura Assigned To: Trustin Lee IPv6 address contains ":" character, so it cannot be used in ObjectName. 2007-10-18 15:37:40,476 WARN [org.jboss.remoting.transport.Connector] Error registering invoker SocketServerInvoker[UNINITIALIZED] with MBeanServer. javax.management.MalformedObjectNameException: Invalid character ':' in value part of property at javax.management.ObjectName.construct(ObjectName.java:529) at javax.management.ObjectName.<init>(ObjectName.java:1304) at org.jboss.remoting.transport.Connector.init(Connector.java:402) at org.jboss.remoting.transport.Connector.create(Connector.java:760) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995) at $Proxy0.create(Unknown Source) at org.jboss.system.ServiceController.create(ServiceController.java:330) at org.jboss.system.ServiceController.create(ServiceController.java:273) at org.jboss.system.ServiceController.create(ServiceController.java:349) at org.jboss.system.ServiceController.create(ServiceController.java:273) at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy4.create(Unknown Source) at org.jboss.deployment.SARDeployer.create(SARDeployer.java:258) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy5.deploy(Unknown Source) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362) at org.jboss.Main.boot(Main.java:200) at org.jboss.Main$1.run(Main.java:508) at java.lang.Thread.run(Thread.java:595) -- 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 months

2
16
0 / 0

[JBoss JIRA] Created: (JBREM-761) NPE in BisocketServerInvoker$ControlConnectionThread

by Ron Sigal (JIRA)

NPE in BisocketServerInvoker$ControlConnectionThread ---------------------------------------------------- Key: JBREM-761 URL: http://jira.jboss.com/jira/browse/JBREM-761 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) >From Tim Fox: Here's one I saw today: @main 18:11:54,129 INFO [FailoverTest] tearing down Exception in thread "control: Socket[addr=/127.0.0.1,port=3243,localport=55075]" java.lang.NullPointerException at org.jboss.remoting.transport.bisocket.BisocketServerInvoker$ControlConnectionThread.run(BisocketServerInvoker.java:669) It seems pretty harmless, but nevertheless I thought I'd inform you. -- 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 months

1
8
0 / 0

[JBoss JIRA] Created: (JBREM-757) Implement quick Client.removeListener() for polled callbacks.

by Ron Sigal (JIRA)

Implement quick Client.removeListener() for polled callbacks. ------------------------------------------------------------- Key: JBREM-757 URL: http://jira.jboss.com/jira/browse/JBREM-757 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) For JBREM-657, quick org.jboss.remoting.Client.disconnect() and quick Client.removeListener() facilities were implemented which impose a per invocation timeout on any network i/o that occurs during these methods. The per invocation timeout is set by calling Client.setDisconnectTimeout(). When the disconnect timeout is set to 0, network i/o is avoided entirely. However, the quick version of Client.removeListener() was implemented only for push callbacks. It should also be implemented for pull callbacks. -- 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 months

1
10
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 May 2008