[jboss-jira] [JBoss JIRA] Closed: (JBREM-639) Allow stream factory to be specified for all transports
[ 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.
Allow stream factory to be specified for all transports
-------------------------------------------------------
Key: JBREM-639
URL: http://jira.jboss.com/jira/browse/JBREM-639
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Reporter: Tim Fox
Assigned To: Ron Sigal
Fix For: 2.4.0.Beta1 (Pinto)
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.
--
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