[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlrpc-user
Subject:    RE: AIX 5.2 Java 1.4 WebServer Garbage in the stream?
From:       "John Southerland" <john () southerland-consulting ! com>
Date:       2005-12-29 21:22:04
Message-ID: 20051229212229.F18EF10FB00D () asf ! osuosl ! org
[Download RAW message or body]

PS: for posterity that string " b9  /32" is the text equivalent of an ssl
handshake.
Enjoy, John

John Buren Southerland
Southerland Consulting
801.467.8090(office)
214.734.8099(cell)
john@southerland-consulting.com

-----Original Message-----
From: John Southerland [mailto:john@southerland-consulting.com] 
Sent: Thursday, December 29, 2005 4:11 PM
To: hwadechandler-apache@yahoo.com
Cc: xmlrpc-user@ws.apache.org
Subject: RE: AIX 5.2 Java 1.4 WebServer Garbage in the stream?

Woops, it turns out httpd is not working on linux either, I did not fully
implement it because I didn't need it until now, and it got left behind in
the code march.
Sorry for the interrupt, RTFM
Thanks again, John

John Buren Southerland
Southerland Consulting
801.467.8090(office)
214.734.8099(cell)
john@southerland-consulting.com
-----Original Message-----
From: Wade Chandler [mailto:hwadechandler-apache@yahoo.com] 
Sent: Thursday, December 29, 2005 4:01 PM
To: xmlrpc-user@ws.apache.org
Subject: Re: AIX 5.2 Java 1.4 WebServer Garbage in the stream?

--- John Southerland <john@southerland-consulting.com>
wrote:

> Wade knocked out my ssl issue in short order, thanks
> again, but I still have
> a connection problem on AIX using http.
> 
> I enabled debug for XmlRpc and tried once again to
> send a message the first
> test, a simple telnet to the port and "GET /
> HTTP/1.0"  returned nothing,
> but printed on the remote in all it's accurate
> glory, however the actually
> xmlrpc request did something more interesting.  I
> didn't capture the raw
> request but it was generated from a linux box
> running jvm 1.5 against the
> remote AIX 5.2 server with a 1.5 jvm as well.
> 
> To make a long setup short, here is the resulting
> output on the server:
> 
>  b9  /32
> 
> java.util.NoSuchElementException
> 
> java.util.NoSuchElementException
> 
>             at
>
java.util.StringTokenizer.nextToken(StringTokenizer.java:347)
> 
>             at
>
org.apache.xmlrpc.WebServer$Connection.run(WebServer.java)
> 
>             at
>
org.apache.xmlrpc.WebServer$Runner.run(WebServer.java)
> 
>             at java.lang.Thread.run(Thread.java:788)
> 
>  
> 
> Anyone seen this before?  Is it network byte order
> versus host byte order
> conversion error or something?
> 
> Once again the same code runs brilliantly on Linux
> and Solaris, fun fun
> 
> Thanks, John
> 
>  
> 
> John Buren Southerland
Should not an issue with the byte order (only matters
for floats and doubles and numbers not character
formatted data), but what appears to be happening (I
haven't looked at the source for WebServer.java, but
it is not checking hasMoreTokens in StringTokenizer
before calling nextToken...I'm not sure exactly what
it is parsing, but if there should be another value
then what really needs to happen is an exception needs
to be thrown stating there should be more elements and
what the real issue is and explain that something
isn't formatted correctly instead of a blind nextToken
read which is what is happening (unless there is no
blind nextToken and hasMoreTokens is checking before
calling nextToken and it is a bug in the IBM jvm).

Wade


[prev in list] [next in list] [prev in thread] [next in thread]