July 2008 - jboss-remoting-issues

[JBoss JIRA] Created: (JBREM-1015) CLONE [JBREM-1014] - Support injection of socket factory class name into AbstractInvoker

by Ron Sigal (JIRA)

CLONE [JBREM-1014] - Support injection of socket factory class name into AbstractInvoker ---------------------------------------------------------------------------------------- Key: JBREM-1015 URL: https://jira.jboss.org/jira/browse/JBREM-1015 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP8 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP9 It is intended that org.jboss.remoting.AbstractInvoker can accept the class name of a SocketFactory, using the parameter org.jboss.remoting.Remoting.SOCKET_FACTORY_NAME (actual value "socketFactory"). Unfortunately, the parameter name "socketFactory" conflicts with the bean property of the same name. In particular, the problem is that the method public void setSocketFactory(SocketFactory socketFactory) in AbstractInvoker expects a SocketFactory instead of a String. -- 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-1011) Release 2.2.2.SP9

by Ron Sigal (JIRA)

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

[JBoss JIRA] Created: (JBREM-1017) Improve socket timeout log message

by Takayoshi Kimura (JIRA)

Improve socket timeout log message ---------------------------------- Key: JBREM-1017 URL: https://jira.jboss.org/jira/browse/JBREM-1017 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Takayoshi Kimura Fix For: 2.2.2.SP7 Attachments: log.zip, testcase.zip When tesing remoting compatibility between AS 4.0.5 and EAP 4.3.0.GA_CP01, I got the following exception messages: In server: 2008-07-22 22:55:57,281 ERROR [org.jboss.remoting.serialization.impl.java.JavaSerializationManager] java.io.EOFException at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2498) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1273) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion1_2(JavaSerializationManager.java:180) at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:130) at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:120) at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59) at org.jboss.remoting.transport.socket.ServerThread.versionedRead(ServerThread.java:663) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:533) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:387) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166) In client: 2008-07-22 22:55:57,178 ERROR [org.jboss.remoting.transport.socket.SocketClientInvoker] Got marshalling exception, exiting java.net.SocketException: Broken pipe at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:66) at java.io.BufferedOutputStream.write(BufferedOutputStream.java:110) at java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1647) at java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode(ObjectOutputStream.java:1556) at java.io.ObjectOutputStream.writeFatalException(ObjectOutputStream.java:1357) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:281) at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObject(JavaSerializationManager.java:81) at org.jboss.remoting.marshal.serializable.SerializableMarshaller.write(SerializableMarshaller.java:84) at org.jboss.invocation.unified.marshall.InvocationMarshaller.write(InvocationMarshaller.java:66) at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:273) at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143) at org.jboss.remoting.Client.invoke(Client.java:525) at org.jboss.remoting.Client.invoke(Client.java:488) at org.jboss.invocation.unified.interfaces.UnifiedInvokerProxy.invoke(UnifiedInvokerProxy.java:175) at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70) at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100) at $Proxy1.remove(Unknown Source) at com.redhat.jboss.support.support192039.TestClient.main(TestClient.java:39) Actually it was just a socket timeout. However, there is information for socket timeout unless we set TRACE log level on org.jboss.remoting. Need more clearer log message at least DEBUG 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, 9 months

2
7
0 / 0

[JBoss JIRA] Created: (JBREM-1014) Support injection of socket factory class name into AbstractInvoker

by Ron Sigal (JIRA)

Support injection of socket factory class name into AbstractInvoker ------------------------------------------------------------------- Key: JBREM-1014 URL: https://jira.jboss.org/jira/browse/JBREM-1014 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP8 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP9 It is intended that org.jboss.remoting.AbstractInvoker can accept the class name of a SocketFactory, using the parameter org.jboss.remoting.Remoting.SOCKET_FACTORY_NAME (actual value "socketFactory"). Unfortunately, the parameter name "socketFactory" conflicts with the bean property of the same name. In particular, the problem is that the method public void setSocketFactory(SocketFactory socketFactory) in AbstractInvoker expects a SocketFactory instead of a String. -- 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

2
8
0 / 0

[JBoss JIRA] Created: (JBREM-1013) Assure version compatibility with earlier versions of Remoting

by Ron Sigal (JIRA)

Assure version compatibility with earlier versions of Remoting -------------------------------------------------------------- Key: JBREM-1013 URL: https://jira.jboss.org/jira/browse/JBREM-1013 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP9 -- 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
1
0 / 0

[JBoss JIRA] Created: (JBREM-961) Context closing handshake is broken

by David Lloyd (JIRA)

Context closing handshake is broken ----------------------------------- Key: JBREM-961 URL: http://jira.jboss.com/jira/browse/JBREM-961 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.0.0-M3 Guess I just half-finished it. It needs to be rethought/fixed. See ContextClient.handlerClosing(boolean). -- 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

15 years, 9 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-1010) Add feature to declaratively turn on leasing for 2.2.2

by Jay Howell (JIRA)

Add feature to declaratively turn on leasing for 2.2.2 ------------------------------------------------------ Key: JBREM-1010 URL: http://jira.jboss.com/jira/browse/JBREM-1010 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: general Affects Versions: 2.2.2.SP7 Reporter: Jay Howell We have a request to declaratively turn on leasing. Currently you can only do it via debugging. Here's the conversation from Ron so far. It says more than I could. -------------------------------------------------------------- The problem lies in org.jboss.aspects.remoting.InvokeRemoteInterceptor, which (1) opens an org.jboss.remoting.Client, (2) makes the invocation, and (3) closes the Remoting client. I guess that's because there's no notion of a "session" or a "lifetime" with EJBs, so there's no other natural place to close the Client. The other part of the story is the relationship between Client and the actual invoker, org.jboss.remoting.transport.socket.MicroSocketClientInvoker in this case. Multiple Clients connected to the same server will share an invoker, increasing its reference count. So if multiple threads were calling on the same EJB at the same time, closing the connection after an invocation wouldn't close the MicroSocketClientInvoker (and its cache of connections) if another thread was in the middle of another invocation. The gap in my explanation is the lack of evidence of multithreading in the example. I don't know what method1() is doing. But if there were some simultaneous processing going on, then enabling leasing would add an extra invocation to the process of connecting and disconnecting, thereby changing the timing of things, which might then lead to keeping a MicroSocketClientInvoker alive long enough to be reused. Unfortunately, there's no declarative way to turn on leasing. Just an oversight, I guess, and it's never come up so I never thought about fixing it. I could, though. However, there's a more direct approach. I put a feature in Remoting 2.4 which makes it possible to configure Client.disconnect() to delay the destruction of the client invoker by putting it in a TimerTask: JBREM-877 "New Socket Connection is being Created for Every Client Request to the Server". On the EJB3 forum thread http://www.jboss.com/index.html?module=bb&op=viewtopic&t=130264, I asked the EJB3 guys to create a JBPAPP issue if they wanted the same feature in Remoting 2.2, but it never happened so I never did it. Since it's certainly a Remoting feature, and not really an EJB3 bug, I guess it's a judgment call whether to go ahead and make the change in Remoting 2.2. But Jay, if you create the JIRA issue(s), I'll be happy to do it and attach a preview jboss-remoting.jar. -------------------------------------------------------------- -- 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

15 years, 9 months

2
4
0 / 0

[JBoss JIRA] Created: (JBREM-1005) Prevent build up of cancelled TimerTasks in bisocket transport

by Ron Sigal (JIRA)

Prevent build up of cancelled TimerTasks in bisocket transport -------------------------------------------------------------- Key: JBREM-1005 URL: http://jira.jboss.com/jira/browse/JBREM-1005 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP8, 2.4.0.GA (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.SP1, 2.2.2.SP9 The behavior of java.util.Timer and java.util.TimerThread is such that a cancelled java.util.TimerTask is removed from the Timer's queue the next time it is executed after being cancelled. JBossMessaging has effectively disabled the bisocket control connection ping mechanism by setting the parameter "pingFrequency" to 214748364, which means that the org.jboss.remoting.transport.bisocket.BisocketServerInvoker.ControlMonitorTimerTask gets created but essentially "never" runs. So when a JBM connection closes, it also shuts down the Remoting bisocket connection, which causes the ControlMonitorTimerTask to get cancelled, but it remains in the Timer queue "forever". -- 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

15 years, 9 months

2
6
0 / 0

[JBoss JIRA] Created: (JBREM-941) SRP SASL integrity/confidentiality protection is failing

by David Lloyd (JIRA)

SRP SASL integrity/confidentiality protection is failing -------------------------------------------------------- Key: JBREM-941 URL: http://jira.jboss.com/jira/browse/JBREM-941 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.0.0-M3 See JrppConnection.java (getSaslProperties) - enable the commented-out line and watch SRP blow up. -- 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

15 years, 9 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-1007) Change all logging to use XNIO Logger class

by David Lloyd (JIRA)

Change all logging to use XNIO Logger class ------------------------------------------- Key: JBREM-1007 URL: http://jira.jboss.com/jira/browse/JBREM-1007 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.0.0-M3 Once conversion is complete, the Logger classes and the corresponding log build modules should be removed from the project. -- 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

15 years, 9 months

1
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues July 2008