[
https://issues.apache.org/jira/browse/XMLRPC-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707180#action_12707180
]
Alan Burlison commented on XMLRPC-169:
--------------------------------------
I think that's part of the issue, yes. However it isn't the whole story,
because even without disconnect() the connections still get closed. I had a
conversation with the engineer who worked on the HttpUrlConnection keepalive
improvements - see
http://blogs.sun.com/chegar/entry/http_keep_alive_improvements - and he pointed
me at http://java.sun.com/j2se/1.5.0/docs/guide/net/http-keepalive.html, which
says:
----------
What makes a connection reusable?
Since TCP by its nature is a stream based protocol, in order to reuse an
existing connection, the HTTP protocol has to have a way to indicate the end of
the previous response and the beginning of the next one. Thus, it is required
that all messages on the connection MUST have a self-defined message length
(i.e., one not defined by closure of the connection). Self demarcation is
achieved by either setting the Content-Length header, or in the case of chunked
transfer encoded entity body, each chunk starts with a size, and the response
body ends with a special last chunk.
----------
so I think the appropriate HTTP headers need to be set as well. This also
seems related to XMLRPC-148.
I'm going to try to get a simple test case together - my current setup uses SSL
which makes it difficult to see what is going on at the network level. If I
can see the HTTP headers I may be able to figure out what is going on.
> XmlRpcSunHttpTransport creates a new connection for every request.
> ------------------------------------------------------------------
>
> Key: XMLRPC-169
> URL: https://issues.apache.org/jira/browse/XMLRPC-169
> Project: XML-RPC
> Issue Type: Bug
> Components: Source
> Affects Versions: 3.1.3
> Environment: Solaris
> Reporter: Alan Burlison
>
> An instance of XmlRpcSunHttpTransport creates a new connection to the server
> for every request that is made via it. That's *horrendously* expensive where
> the connection is a SSL connection.
> Here's a trace, note the repeated connect() calls.
> /2: connect(20, 0xFE32E4D0, 32, SOV_DEFAULT) = 0
> /2: getsockname(20, 0xFE32E4D0, 0xFE32E618, SOV_DEFAULT) = 0
> /2: setsockopt(20, tcp, TCP_NODELAY, 0xFE32E768, 4, SOV_DEFAULT) = 0
> /2: send(20, " P O S T / H T T P /".., 283, 0) = 283
> /2: send(20, " < ? x m l v e r s i o".., 215, 0) = 215
> /2: read(20, " H T T P / 1 . 0 2 0 0".., 8192) = 84
> /2: read(20, " < ? x m l v e r s i o".., 8108) = 202
> /2: ioctl(20, FIONREAD, 0xFE32E684) = 0
> /2: fcntl(21, F_DUP2FD, 0x00000014) = 20
> /2: close(20) = 0
> /2: so_socket(PF_INET6, SOCK_STREAM, IPPROTO_IP, 0x00000000, SOV_DEFAULT) =
> 20
> /2: connect(20, 0xFE32E4D0, 32, SOV_DEFAULT) = 0
> /2: getsockname(20, 0xFE32E4D0, 0xFE32E618, SOV_DEFAULT) = 0
> /2: setsockopt(20, tcp, TCP_NODELAY, 0xFE32E768, 4, SOV_DEFAULT) = 0
> /2: send(20, " P O S T / H T T P /".., 283, 0) = 283
> /2: send(20, " < ? x m l v e r s i o".., 215, 0) = 215
> /2: read(20, " H T T P / 1 . 0 2 0 0".., 8192) = 84
> /2: read(20, " < ? x m l v e r s i o".., 8108) = 202
> /2: ioctl(20, FIONREAD, 0xFE32E684) = 0
> /2: fcntl(21, F_DUP2FD, 0x00000014) = 20
> /2: close(20) = 0
> /2: so_socket(PF_INET6, SOCK_STREAM, IPPROTO_IP, 0x00000000, SOV_DEFAULT) =
> 20
> /2: connect(20, 0xFE32E4D0, 32, SOV_DEFAULT) = 0
> /2: getsockname(20, 0xFE32E4D0, 0xFE32E618, SOV_DEFAULT) = 0
> /2: setsockopt(20, tcp, TCP_NODELAY, 0xFE32E768, 4, SOV_DEFAULT) = 0
> /2: send(20, " P O S T / H T T P /".., 283, 0) = 283
> /2: send(20, " < ? x m l v e r s i o".., 215, 0) = 215
> /2: read(20, " H T T P / 1 . 0 2 0 0".., 8192) = 84
> /2: read(20, " < ? x m l v e r s i o".., 8108) = 202
> /2: ioctl(20, FIONREAD, 0xFE32E684) = 0
> /2: fcntl(21, F_DUP2FD, 0x00000014) = 20
> /2: close(20) = 0
> /2: so_socket(PF_INET6, SOCK_STREAM, IPPROTO_IP, 0x00000000, SOV_DEFAULT) =
> 20
> /2: connect(20, 0xFE32E4D0, 32, SOV_DEFAULT) = 0
> /2: getsockname(20, 0xFE32E4D0, 0xFE32E618, SOV_DEFAULT) = 0
> /2: setsockopt(20, tcp, TCP_NODELAY, 0xFE32E768, 4, SOV_DEFAULT) = 0
> /2: send(20, " P O S T / H T T P /".., 283, 0) = 283
> /2: send(20, " < ? x m l v e r s i o".., 215, 0) = 215
> /2: read(20, " H T T P / 1 . 0 2 0 0".., 8192) = 84
> /2: read(20, " < ? x m l v e r s i o".., 8108) = 202
> /2: ioctl(20, FIONREAD, 0xFE32E684) = 0
> /2: fcntl(21, F_DUP2FD, 0x00000014) = 20
> /2: close(20) = 0
> And if you assume that a major use of the Apache XML-RPC client is with the
> Apache XML-RPC server, it means the keepalive support in the server is pretty
> much a waste of time.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
