ws-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Theis <>
Subject Beta: Bug, Wishes and Suggestions
Date Sat, 17 May 2003 20:24:59 GMT

I'm using the beta (downloaded it a few days ago) and I have some
questions and suggestions:

1, the bug. In, about line 290, you have the following

while (call != null)
  call = dequeue();
  executeAsync(call.request, call.callback, call.transport);

This throws a NullPointerException. I think the code must be as
follows (dequeue and executeAsync exchanged):

while (call != null)
  executeAsync(call.request, call.callback, call.transport);
  call = dequeue();

2, the wish: Can you make the class ServerInputStream public? I want
(or I have to) implement my own transport class, derived from
LiteXmlRpcTransport, and I would like to use this class as well.

3, the suggestions: The reason for 2: In LiteXmlRpcTransport, you are
creating a BufferedOutputStream with the default size of 512 bytes.
That's pretty small, event the TCP layer can handle about 3 times this
size. The disadvantage of this small buffersize is: When the call is
larger than those 512 Bytes, first the header will be written and then
the remaining data. But the sockets are blocking, so writing the
header you will have to wait for the ACK from the server. But the
server (or the underlying TCP stack) will wait for more data and only
after a timeout (about 100ms or more) will send the ACK. The total
cost of my call is about a few ms, but most of the time I had to wait
for the ACK from the server! This is a significant performance hit!
With the Beta you have a better class design, making it easier to
overload and work around this buffer problem. But perhaps you could
provide a way to set the buffer size from extern, or try to send the
request in one call, making the buffer the size of the request plus

4, a question: The former version were very small, a jar file of about
50kB. Now, I need the codecs (a large jar file) and probably the
httpclient (a huge jar file). I see the point of having just one code
to implement the Base64 encoding / decoding. I don't see the point of
having a multi-purpose-client, which can handle cookies, show frames,
enlarge my penis size, ... *ooops* ;) I don't know, if I can use the
xmlrpc jaf file without the codecs (I don't use Base64 at the moment)
and without the http client. I compiled the sources without servelet
and applet (removed it from the source) but I still need the codec.
But then, it's not your code anymore, and this is the problem! I would
like if you could split the code somehow, so one could use the small
xmlrpc client alone and add codec and especially the http client only
if needed, as an add-on.

Kind regards


View raw message