February 2009 - jboss-remoting-issues

[JBoss JIRA] Created: (JBREM-1083) Each Client creates a new invokerDestructionTimer

by Ron Sigal (JIRA)

Each Client creates a new invokerDestructionTimer ------------------------------------------------- Key: JBREM-1083 URL: https://jira.jboss.org/jira/browse/JBREM-1083 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP12, 2.5.0.SP3 (Flounder) When the parameter "invokerDestructionDelay" is greater than 0, org.jboss.remoting.Client.disconnect() creates a new TImer. There should be one static Timer. -- 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

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-1103) Correct javadoc for Client.invokeOneway()

by Ron Sigal (JIRA)

Correct javadoc for Client.invokeOneway() ----------------------------------------- Key: JBREM-1103 URL: https://jira.jboss.org/jira/browse/JBREM-1103 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11 Reporter: Ron Sigal Assignee: Ron Sigal Priority: Minor Fix For: 2.2.2.SP12, 2.5.0.SP3 (Flounder) The javadoc discussion on org.jboss.remoting.Client.invokeOneway() is no longer correct when the value of clientSide is false. In particular, it is incorrect for the socket transport, since org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport() returns immediately after sending an invocation when it detects a oneway invocation. This behavior has been true since the implementation of JBREM-548 "Support one way invocations with no response". -- 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

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1076) SocketServerInvoker.processInvocation() should return if running == false

by Ron Sigal (JIRA)

SocketServerInvoker.processInvocation() should return if running == false ------------------------------------------------------------------------- Key: JBREM-1076 URL: https://jira.jboss.org/jira/browse/JBREM-1076 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.0.SP3 (Flounder) The while(worker == null && running) loop can end with worker == null, in which case processRequest() should return instead of proceeding. -- 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

1
5
0 / 0

[JBoss JIRA] Created: (JBREM-1099) Make MulticastDetector detection message send buffer size configurable

by Galder Zamarreno (JIRA)

Make MulticastDetector detection message send buffer size configurable ---------------------------------------------------------------------- Key: JBREM-1099 URL: https://jira.jboss.org/jira/browse/JBREM-1099 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP12 Reporter: Galder Zamarreno The multicast detector does not work properly in environments where plenty Remoting invokers are used, such as the case of EAP 4.3 where you have invokers for EJB3, EJB2, JMS...etc. What happens is that org.jboss.remoting.detection.AbstractDetector.createDetection(), it creates a detection message based on the server invokers registered locally. As there's one more invoker in EAP 4.3.x, the message size exceeds the 4000 limit. This leads to errors like: 2009-02-12 15:19:26,846 DEBUG [org.jboss.remoting.detection.multicast.MulticastDetector] heartbeat failed java.io.IOException: Message too long at java.net.PlainDatagramSocketImpl.send(Native Method) at java.net.DatagramSocket.send(DatagramSocket.java:612) at org.jboss.remoting.detection.multicast.MulticastDetector.heartbeat(MulticastDetector.java:226) at org.jboss.remoting.detection.AbstractDetector$Heartbeat.run(AbstractDetector.java:716) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) The size of the buffer where the Detection message is sent comes from: private final class Listener extends Thread { boolean running = true; public Listener(String name) { super(name); } public void run() { byte[] buf = new byte[4000]; DatagramPacket p = new DatagramPacket(buf, 0, buf.length); //p.setAddress(addr); //p.setPort(port); while(running) { listen(p, buf); } } } The size of the buffer needs to be made configurable. -- 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
8
0 / 0

[JBoss JIRA] Created: (JBREM-1081) Fix NPE in ServerInvokerCallbackHandler

by Ron Sigal (JIRA)

Fix NPE in ServerInvokerCallbackHandler ---------------------------------------- Key: JBREM-1081 URL: https://jira.jboss.org/jira/browse/JBREM-1081 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11 Reporter: Ron Sigal Assignee: Ron Sigal Priority: Minor Fix For: 2.2.2.SP12, 2.5.0.SP3 (Flounder) When org.jboss.remoting.callback.ServerInvokerCallback is shut down by a call to ServerInvokerCallbackHandler.destroy(), the variables callBackClient and callbackStore are set to null. If ServerInvokerCallbackHandler.handleCallback() is called subsequently (which can happen if destroy() is called by ServerInvokerCallbackHandler.handleConnectionException() and the application has not yet been informed about a connection failure), then, since callbackClient == null, it looks like pull callbacks are configured, but, since callbackStore == null, a NullPointerException is thrown in ServerInvokerCallbackHandler.persistCallback(). -- 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

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-1085) Reduce log level of ServerSocketWrapper.close() log messages

by Ron Sigal (JIRA)

Reduce log level of ServerSocketWrapper.close() log messages ------------------------------------------------------------ Key: JBREM-1085 URL: https://jira.jboss.org/jira/browse/JBREM-1085 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11 Reporter: Ron Sigal Assignee: Ron Sigal Priority: Minor Fix For: 2.2.2.SP12, 2.5.0.SP3 (Flounder) The log messages "wrote CLOSING" and "unable to writing CLOSING byte" in org.jboss.remoting.transport.socket.ServerSocketWrapper.close() are too noisy and should be reduced to TRACE level. -- 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

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1039) Release 2.2.2.SP11

by Ron Sigal (JIRA)

Release 2.2.2.SP11 ------------------ Key: JBREM-1039 URL: https://jira.jboss.org/jira/browse/JBREM-1039 Project: JBoss Remoting Issue Type: Release Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP11 -- 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

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1072) Synchronize access to static maps in MarshalFactory

by Ron Sigal (JIRA)

Synchronize access to static maps in MarshalFactory --------------------------------------------------- Key: JBREM-1072 URL: https://jira.jboss.org/jira/browse/JBREM-1072 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP10 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP11, 2.5.0.SP3 (Flounder) Users have experienced the exception org.jboss.remoting.marshal.InvalidMarshallingResource: Can not find a valid marshaller for data type: serializable at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:79) at org.jboss.remoting.Client.invoke(Client.java:1634) at org.jboss.remoting.Client.invoke(Client.java:548) at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:67) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:107) This is strange, since a marshaller for the datatype "serializable" is hardcoded in org.jboss.remoting.marshal.MarshalFactory. However, access to the static Map marshallers is not synchronized, so it's possible that one subsystem is adding a marshaller (e.g., EJB2, JBossMessaging) at the same time that EJB3 is trying to extract a marshaller. The same observation applies to unmarshallers. -- 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
5
0 / 0

[JBoss JIRA] Created: (JBREM-1098) Remoting 2 discovery protocol emulation

by David Lloyd (JIRA)

Remoting 2 discovery protocol emulation --------------------------------------- Key: JBREM-1098 URL: https://jira.jboss.org/jira/browse/JBREM-1098 Project: JBoss Remoting Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: 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, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-1097) Remoting 2 servlet http protocol server emulation

by David Lloyd (JIRA)

Remoting 2 servlet http protocol server emulation ------------------------------------------------- Key: JBREM-1097 URL: https://jira.jboss.org/jira/browse/JBREM-1097 Project: JBoss Remoting Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: 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, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues February 2009