binary data length

["Koch, Andreas(init)" <An...@init.de>]

Hello,

I habe the following problem!

server-side
=============
public class Test
{
	public byte[] getBin(int count)
	{
		byte[] data = new byte[count];
		for (int i = 0; i< count; i++ )
		{
			data[i] = 34;
		}
		return data;
	}
}

client-side
=============
byte[] data = null;
int count = 100000;
try
    {
		String endpoint =
"http://localhost:80/bund/servlet/AxisServlet";
       	ServiceClient client = new ServiceClient(endpoint);
	   	Object[] params = new Object[1];
	      params[0] = new Integer(count);
	   	data = (byte[])client.invoke("TestService","getBin",params);
	}catch(Exception ex)
    {
		ex.printStackTrace ();
    }

Error
=======
System.out.println(data.length()); 
(results in )
>> 1696 


Thanks for any idea that helps.

Andreas

Re: binary data length

[Marc Martinez <la...@technogeeks.org>]

On Tue, Nov 20, 2001 at 04:28:30PM +0100, Koch, Andreas(init) wrote:
> Hello,
> 
> I habe the following problem!
[snip]
> client-side
> =============
> byte[] data = null;
> int count = 100000;
[snip]
> Error
> =======
> System.out.println(data.length()); 
> (results in )
> >> 1696 
> 
> 
> Thanks for any idea that helps.

this looks like you got bit by the "12k buffer wrap" I've been
struggling with lately, and just last night implemented a workaround
for.  the reason I suggest this is:

% echo "100000%12288"|bc
1696

at first I (naively) thought it was a problem with the Base64 handler
routines, but I've since proven to myself that it's not specific to
that at all (other than possibly by virtue of handling the byte[]
arrays, but I haven't done much investigating in that area)..
stepping through the code with a debugger showed me that the result
passed back into the Call object was already truncated/overflowed,
however inspecting the MessageContext associated with the Call object
plainly showed that all my data was available.

the problem only manifests (in my test cases anyway) with the
client-side code, I can pack it up with a quick jws service and send
it all out cleanly, and using perl's SOAPsh.pl script see the entire
results with no problems..

so, being that the message context had all the original data intact, I
switched from using RPC calls to building my own request message, and
running the response message through a quick sax filter that builds up
a char[] array of the base64'd content, and then I convert that back
to a regular byte[] array (using the Base64 class) to make my original
original code happy.

I was actually going to post a followup to my original plea for help
explaining what I'd found, so your request was quite timely. :)

hopefully this gives you a viable workaround until one of the
developers can acknowledge and track this nastiness down (I track cvs
nightly drops fairly regularly, and have consistently had this
problem).  look to the AdminClient if you need an example for doing
the message-based handling, and if all else fails send me a request
via private mail and I'll send along some of the code I'm working with.

Marc