[ http://jira.jboss.com/jira/browse/JBREM-639?page=all ] Tim Fox updated JBREM-639: -------------------------- Fix Version/s: 2.2.0.Alpha4 -- 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

[ http://jira.jboss.com/jira/browse/JBREM-639?page=all ] Tim Fox updated JBREM-639: -------------------------- Description: Normally marshallers will receive the raw underlying transport Input/OuputStream. In some cases we want to wrap this in a different stream, e.g.in the case of JBossMessaging we want this wrapped in a DataInput/DataOutputStream. This is accomplished by specifiying a new Client/ServerSocketWrapper in the socket transport URI params which creates the DataInput/OutputStream. This works fine for the socket transport, but does not work for other transports which do not use SocketWrappers. E.g. JBM needs to use the HTTP transport too, and needs the underlying stream wrapped in a DataOutput/InputStream. The current remoting implementation will pass in the underlying stream to the marshaller when the HTTP transport is used, which means we have create and wrap a new DataInput/OuputStream on each invocation request and response which may have performance implications. Suggestion is to allow a InputStream/OuputStream factory to be specified for ANY transport, not just the socket transport. Suggestion is to allow the stream factory to be specified in the URI params, e.g. &streamFactoryClass=org.jboss.tim.MyStreamFactory, and this to be allowed for any transport. If factory is not specified then raw stream is passed into marshaller. was: Normally marshallers will receive the raw underlying transport Input/OuputStream. In some cases we want to wrap this in a different stream, e.g.in the case of JBossMessaging we want this wrapped in a DataInput/DataOutputStream. This is accomplished by specifiying a new Client/ServerSocketWrapper in the socket transport URI params which creates the DataInput/OutputStream. This works fine for the socket transport, but does not work for other transports which do not use SocketWrappers. E.g. JBM needs to use the HTTP transport too, and needs the underlying stream wrapped in a DataOutput/InputStream. The current remoting implementation will pass in the underlying stream to the marshaller when the HTTP transport is used, which means we have create and wrap a new DataInput/OuputStream on each invocation request and response which may have performance implications. Suggestion is to allow a InputStream/OuputStream factory to be specified for ANY transport, not just the socket transport. This would allow how streams are wrapped to be determined in a much more consistent way. Suggestion is to allow the stream factory to be specified in the URI params, e.g. &streamFactoryClass=org.jboss.tim.MyStreamFactory, and this to be allowed for any transport. If factory is not specified then raw stream is passed into marshaller. -- 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

[ http://jira.jboss.com/jira/browse/JBREM-639?page=all ] Tom Elrod updated JBREM-639: ----------------------------- Fix Version/s: 2.2.0.Beta2 (Boon) (was: 2.2.0.Beta1 (Bluto)) -- 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

[ http://jira.jboss.com/jira/browse/JBREM-639?page=all ] Ron Sigal closed JBREM-639. --------------------------- Resolution: Won't Fix This issue is primarily of interest in the context of the Remoting http transport, but the implementation (at least the Sun jdk implementation) of java.net.HttpURLConnection seems to make this optimization impossible. The idea would be to create and store input and output streams, e.g., object streams, for each socket used by the HttpURLConnection and then reuse them. Unfortunately, the output stream returned by Sun's implementation of HttpURLConnection.getOutputStream() are not the socket streams associated with the underlying socket, but are instances of sun.net.www.http.PosterOutputStream, which extends ByteArrayOutputStream. Each new HttpURLConnection returns a new PosterOutputStream, so there seems to be no way to key on the underlying socket streams to reuse existing higher level streams. This feature request will be tabled for now. One option would be to look into HttpClient from the Apache HttpComponents project. However, the issue should be rendered moot by the advent of Remoting 3. -- 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

[ http://jira.jboss.com/jira/browse/JBREM-639?page=all ] Ron Sigal updated JBREM-639: ---------------------------- Fix Version/s: (was: 2.4.0.Beta1 (Pinto)) Removed fix version. -- 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

[ http://jira.jboss.com/jira/browse/JBREM-639?page=all ] Ron Sigal reopened JBREM-639: ----------------------------- -- 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