August 2008 - jboss-remoting-issues

[JBoss JIRA] Updated: (JBREM-925) SSLSocketBuilder config attribute names out of sync with docs

by Ron Sigal (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-925?page=com.atlassian.jira.plug... ] Ron Sigal updated JBREM-925: ---------------------------- Summary: SSLSocketBuilder config attribute names out of sync with docs (was: SSLSocketBuilder config attribute names out of sync with v2.2 docs) Fix Version/s: 2.2.2.SP10 Affects Version/s: 2.2.2.SP8 2.4.0.GA (Pinto) > SSLSocketBuilder config attribute names out of sync with docs > ------------------------------------------------------------- > > Key: JBREM-925 > URL: https://jira.jboss.org/jira/browse/JBREM-925 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: docs > Affects Versions: 2.4.0.GA (Pinto), 2.2.2.SP8 > Reporter: Tom Fennelly > Assignee: Ron Sigal > Fix For: 2.4.0.SP1, 2.2.2.SP10 > > > The latest docs available for download are for 2.2.0.GA (http://labs.jboss.org/jbossremoting/docs/index.html). > Table 5.1 (in pdf) outlines the attribute names for configuring the SSLSocketBuilder. They're not consistent with the actual definitions in the SSLSocketBuilder class, so errors result when used as per the docs. > In the ESB, we do a manual mapping of the names in code, so we get around the issue, but other users may be stumped. -- 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
0
0 / 0

[JBoss JIRA] Created: (JBREM-1022) Fix misleading javadoc in InvokerLocator

by Ron Sigal (JIRA)

Fix misleading javadoc in InvokerLocator ---------------------------------------- Key: JBREM-1022 URL: https://jira.jboss.org/jira/browse/JBREM-1022 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP9, 2.4.0.GA (Pinto) Reporter: Ron Sigal Assignee: Ron Sigal Priority: Minor Fix For: 2.4.0.SP1, 2.2.2.SP10 The following note in the org.jboss.remoting.InvokerLocator javadoc is incorrect: * NOTE: the hostname will automatically be resolved to the outside IP address of the local machine * if <tt>localhost</tt> or <tt>127.0.0.1</tt> is used as the hostname in the URI. If it cannot be * determined or resolved, it will use what was passed. In fact, it is only a missing hostname (and 0.0.0.0 in the special case that the system property "jboss.bind.address" is set) that will be replaced. -- 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-1012) CLONE [JBREM-1010] - Add feature to declaratively turn on leasing for 2.4.0

by Ron Sigal (JIRA)

CLONE [JBREM-1010] - Add feature to declaratively turn on leasing for 2.4.0 --------------------------------------------------------------------------- Key: JBREM-1012 URL: https://jira.jboss.org/jira/browse/JBREM-1012 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: general Affects Versions: 2.2.2.SP7 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP9 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: 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
4
0 / 0

[JBoss JIRA] Commented: (JBREM-904) Remoting 1/2 protocol compatibility

by David Lloyd (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-904?page=com.atlassian.jira.plug... ] David Lloyd commented on JBREM-904: ----------------------------------- Per IRC chat on Aug. 5 2008 - probable design would consist of: * RequestHandler implementations that implement the various R1/2 client protocols * Servers that understand the R1/2 protocols which forward requests on to RequestHandlers * Some way to use R2 service discovery to set up these clients and servers It is possible that it is prohibitively complex to implement the entire protocol, at which point we'd have to have further discussions. > Remoting 1/2 protocol compatibility > ----------------------------------- > > Key: JBREM-904 > URL: https://jira.jboss.org/jira/browse/JBREM-904 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: David Lloyd > Fix For: 3.0.0-M3 > > > A protocol compatibility layer needs to be developed that allows a Remoting 3 server to respond to a Remoting 1/2 request, and also that allows a Remoting 3 client to connect to a Remoting 1/2 server. This will be required before integration with AS5 can be considered. > Another item worth exploration is looking into providing a Remoting 1/2 compatibilty API that allows legacy applications to use the newer transports. -- 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
0
0 / 0

[JBoss JIRA] Closed: (JBREM-812) Specify an API to discover services

by David Lloyd (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-812?page=com.atlassian.jira.plug... ] David Lloyd closed JBREM-812. ----------------------------- Resolution: Done Endpoint.registerRemoteService(), Endpoint.createRequestHandlerSource(), Endpoint.addServiceListener() meet this need. > Specify an API to discover services > ----------------------------------- > > Key: JBREM-812 > URL: https://jira.jboss.org/jira/browse/JBREM-812 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Components: r3 api > Reporter: David Lloyd > Assignee: David Lloyd > Priority: Minor > Fix For: 3.0.0-M3 > > > The Remoting 3 API presently has a mechanism to discover endpoints and supply information about how to connect to discovered endpoints. > A mechanism is also needed to allow a user to find any endpoint that provides a specific service. This mechanism would preferably work in tandem with the existing discovery API. -- 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
0
0 / 0

[JBoss JIRA] Created: (JBREM-963) Work out a mechanism to handle protocol message ordering issues across multiple channels

by David Lloyd (JIRA)

Work out a mechanism to handle protocol message ordering issues across multiple channels ---------------------------------------------------------------------------------------- Key: JBREM-963 URL: http://jira.jboss.com/jira/browse/JBREM-963 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.0.0-M3 When dealing with a protocol using multiple channels (HTTP for example, and possibly a future multi-channel JRPP variant), sending two messages on two different channels can cause ordering issues if the second message sent arrives first. For example, sending a context open on channel A, and a request on channel B, may cause the request to be received before the context open message, resulting in the request being rejected with a "no such context" error. Another example is that stream messages must be handled sequentially. There are several possible solutions, including but not limited to: * for any message B that must come after A, always send A and B on the same channel (problem: HTTP channels are transient, so this won't work for HTTP) (problem: this could load up one channel while leaving other channels empty, even if load-balancing is used) * don't send B until after A is acknowledged (problem: acknowledging A might not be possible within the underlying protocol, like if A is sent in an HTTP reply, requiring a separate ACK message, which can lead to performance problems) * if a message comes in seemingly unsolicited (like a request on a nonexistant context) or out of sequence (like in a stream), queue the message for some fixed amount of time to see if the context open message arrives (problem: could be a source of DoS on the server; also this is a duplication of what protocols like TCP already do, which means that all the same problems must be in effect re-solved) Starting a forum thread to discuss the topic. -- 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, 8 months

1
3
0 / 0

[JBoss JIRA] Updated: (JBREM-833) HTTP Transport Implementation

by David Lloyd (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-833?page=com.atlassian.jira.plug... ] David Lloyd updated JBREM-833: ------------------------------ Assignee: (was: David Lloyd) > HTTP Transport Implementation > ----------------------------- > > Key: JBREM-833 > URL: https://jira.jboss.org/jira/browse/JBREM-833 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: David Lloyd > Fix For: 3.1.0.GA > > -- 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
0
0 / 0

[JBoss JIRA] Created: (JBREM-1021) JavaSerializationManager should not log exceptions at ERROR level

by Ron Sigal (JIRA)

JavaSerializationManager should not log exceptions at ERROR level ----------------------------------------------------------------- Key: JBREM-1021 URL: https://jira.jboss.org/jira/browse/JBREM-1021 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP9 Reporter: Ron Sigal Assignee: Ron Sigal Priority: Minor Fix For: 2.2.2.SP10 If a client disconnects normally, org.jboss.remoting.serialization.impl.java.JavaSerializationManager logs EOFException at ERROR level: ERROR [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) The Exception should just be thrown. -- 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] Commented: (JBREM-925) SSLSocketBuilder config attribute names out of sync with v2.2 docs

by Tom Fennelly (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-925?page=com.atlassian.jira.plug... ] Tom Fennelly commented on JBREM-925: ------------------------------------ Just thought I'd add a link to the relevant docs (see the "attribute" column): http://www.jboss.org/jbossremoting/docs/guide/2.4/html_single/index.html#... So this is not an issue where people are configuring JBR through code... they can use the statics on SSLSocketBuilder. It's an issue in the likes of the ESB because the configuration is happening through XML and if they use these docs to add the configs, then I think they will assume the attribute name should be that defined in the "attribute" column. Posting this info here because I got an email from Ron over the weekend and I thought it would be better to reply here :-) > SSLSocketBuilder config attribute names out of sync with v2.2 docs > ------------------------------------------------------------------ > > Key: JBREM-925 > URL: https://jira.jboss.org/jira/browse/JBREM-925 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: docs > Reporter: Tom Fennelly > Assignee: Ron Sigal > Fix For: 2.4.0.SP1 > > > The latest docs available for download are for 2.2.0.GA (http://labs.jboss.org/jbossremoting/docs/index.html). > Table 5.1 (in pdf) outlines the attribute names for configuring the SSLSocketBuilder. They're not consistent with the actual definitions in the SSLSocketBuilder class, so errors result when used as per the docs. > In the ESB, we do a manual mapping of the names in code, so we get around the issue, but other users may be stumped. -- 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
0
0 / 0

[JBoss JIRA] Commented: (JBREM-925) SSLSocketBuilder config attribute names out of sync with v2.2 docs

by Tom Fennelly (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-925?page=com.atlassian.jira.plug... ] Tom Fennelly commented on JBREM-925: ------------------------------------ Exactly... it's a docs issue. Someone following the docs will try to configure JBR using invalid attribute names. In the ESB, we try to avoid any potential issue by performing the mapping shown at the end of the JBossRemotingGatewayListener class (http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/rosetta/s...). This way, if the user enters the attributes names as per the docs, we map them to the correct names. > SSLSocketBuilder config attribute names out of sync with v2.2 docs > ------------------------------------------------------------------ > > Key: JBREM-925 > URL: https://jira.jboss.org/jira/browse/JBREM-925 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: docs > Reporter: Tom Fennelly > Assignee: Ron Sigal > Fix For: 2.4.0.SP1 > > > The latest docs available for download are for 2.2.0.GA (http://labs.jboss.org/jbossremoting/docs/index.html). > Table 5.1 (in pdf) outlines the attribute names for configuring the SSLSocketBuilder. They're not consistent with the actual definitions in the SSLSocketBuilder class, so errors result when used as per the docs. > In the ESB, we do a manual mapping of the names in code, so we get around the issue, but other users may be stumped. -- 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
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues August 2008