[
https://issues.apache.org/jira/browse/XMLRPC-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707442#action_12707442
]
Alan Burlison commented on XMLRPC-169:
--------------------------------------
I've got a test case together, and there are two immediately obvious issues.
Here is an example transaction, from the client end:
/2: connect(21, 0xFE32E4D0, 32, SOV_DEFAULT) = 0
/2: send(21, 0xFE32C730, 283, 0) = 283
/2: P O S T / H T T P / 1 . 1\r\n C o n t e n t - T y p e : t
/2: e x t / x m l\r\n U s e r - A g e n t : A p a c h e X M L
/2: R P C $ { p r o j e c t . v e r s i o n } ( S u n H T T P
/2: T r a n s p o r t )\r\n C o n t e n t - L e n g t h : 2 1 5
/2: \r\n C a c h e - C o n t r o l : n o - c a c h e\r\n P r a g m
/2: a : n o - c a c h e\r\n H o s t : l o c a l h o s t : 8 8 8
/2: 8\r\n A c c e p t : t e x t / h t m l , i m a g e / g i f ,
/2: i m a g e / j p e g , * ; q = . 2 , * / * ; q = .
2\r
/2: \n C o n n e c t i o n : k e e p - a l i v e\r\n\r\n
/2: send(21, 0xFE32C760, 215, 0) = 215
/2: < ? x m l v e r s i o n = " 1 . 0 " e n c o d i n g = " U T
/2: F - 8 " ? > < m e t h o d C a l l > < m e t h o d N a m e > u p
/2: p e r c a s e < / m e t h o d N a m e > < p a r a m s > < p a r
/2: a m > < v a l u e > o n e < / v a l u e > < / p a r a m > < p a
/2: r a m > < v a l u e > t w o < / v a l u e > < / p a r a m > < p
/2: a r a m > < v a l u e > t h r e e < / v a l u e > < / p a r a m
/2: > < / p a r a m s > < / m e t h o d C a l l >
/2: read(21, 0xFE32C790, 8192) = 84
/2: H T T P / 1 . 0 2 0 0 O K\r\n C o n t e n t - T y p e : t
/2: e x t / x m l ; c h a r s e t = I S O - 8 8 5 9 - 1\r\n c o n
/2: t e n t - l e n g t h : 2 0 2\r\n\r\n
/2: read(21, 0xFE32C670, 8108) = 202
/2: < ? x m l v e r s i o n = " 1 . 0 " e n c o d i n g = " U T
/2: F - 8 " ? > < m e t h o d R e s p o n s e > < p a r a m s > < p
/2: a r a m > < v a l u e > < a r r a y > < d a t a > < v a l u e >
/2: O N E < / v a l u e > < v a l u e > T W O < / v a l u e > < v a
/2: l u e > T H R E E < / v a l u e > < / d a t a > < / a r r a y >
/2: < / v a l u e > < / p a r a m > < / p a r a m s > < / m e t h o
/2: d R e s p o n s e >
/2: close(21)
The first thing to note is that the server is announcing itself as a HTTP1.0
server rather than HTTP1.0. HTTP1.0 requires that the server sends a
"Connection: keep-alive" header to enable keepalives. HTTP1.1 assumes that
keepalive support is enabled unless disabled with a "Connection: close" header,
so either the HTTP version needs changing to 1.1 or the server should send a
keepalive header, I suspect the correct thing to do is to change the HTTP
version string to "HTTP 1.1" *and* so send the appropriate header (see
http://www.io.com/~maus/HttpKeepAlive.html for a concise explanation of how
this is supposed to work). Jochen, what do you think?
I temporarily hacked the XML-RPC server code to announce itself as HTTP1.1 and
send a keepalive header, but that still isn't sufficient - the client correctly
tries to reuse the connection, but the server closes it irrespective of the
headers, and so the client gets a closed socket error. I haven't yet figured
out why the XML-RPC server is closing the connection, but it is clear it needs
further investigation.
> 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.
