Tuning the performance of ObjectInputStream.readObject()

I'm using JWorks, which roughly corresponds to jdk1.1.8, on my client
(VxWorks) and jdk1.4.2 on the server side (Windows, Tomcat).

I'm serializing a big vector and compressing it using GZipOutputStream
on the server side and doing the reverse on the client side to recreate
the objects.

Server side:

Vector v = new Vector(50000);//also filled with 50k different MyObject
instances
ObjectOutputStream oos = new ObjectOutputStream(new
GZipOutputStream(socket.getOutputStream()));
oos.writeObject(v);


Client side:

ObjectInputStream ois = new ObjectInputStream(new
GZipInputStream(socket.getInputStream()));
Vector v = (Vector)ois.readObject();


ObjectInputStream.readObject() at the client takes a long time (50secs)
to complete, which is understandable as the client is a PIII-700MHz and
the uncompressed vector is around 10MB. Now the problem is that because
my Java thread runs with real time priority (which is the default on
Vxworks) and deprive other threads, including non-Java ones, for this
whole 50 sec period. This causes a watchdog thread to reset the system.
I guess most of this delay is in GZipInputStream, as part of the
un-gzipping process.

My question is, is there a way to make ObjectInputStream.readObject()
or any of the other connected streams (gzip and socket) yield the CPU
to other threads once in a while? Or is there any other way to deal
with the situation?

Is the following a good solution?

class MyGZipInputStream extends GZipInputStream {
public int count = 0;

public int read(byte b[], int off, int len) throws IOException {
if(++count %10 == 0) // to avoid too many yields
Thread.yield();
return super.read(b, off,len);
}
}


Thanks
--kannan

kannan123@gmail.com

the yield looks fine....
on the other hand u can decrease the priority of the thread before starting
the de-compress, and then at the end of the de-compress put back the
priority...does JWorks support changing the priority?

final int oldPriority = Thread.currentThread().getPriority();
Thread.currentThread().setPriority(Thread.MIN_PRIO RITY);
try
{
ObjectInputStream ois = new ObjectInputStream(new
GZipInputStream(socket.getInputStream()));
Vector v = (Vector)ois.readObject();
}
finally
{
Thread.currentThread().setPriority(oldPriority);
}
<> wrote in message
news: oups.com...
> I'm using JWorks, which roughly corresponds to jdk1.1.8, on my client
> (VxWorks) and jdk1.4.2 on the server side (Windows, Tomcat).
>
> I'm serializing a big vector and compressing it using GZipOutputStream
> on the server side and doing the reverse on the client side to recreate
> the objects.
>
> Server side:
>
> Vector v = new Vector(50000);//also filled with 50k different MyObject
> instances
> ObjectOutputStream oos = new ObjectOutputStream(new
> GZipOutputStream(socket.getOutputStream()));
> oos.writeObject(v);
>
>
> Client side:
>
> ObjectInputStream ois = new ObjectInputStream(new
> GZipInputStream(socket.getInputStream()));
> Vector v = (Vector)ois.readObject();
>
>
> ObjectInputStream.readObject() at the client takes a long time (50secs)
> to complete, which is understandable as the client is a PIII-700MHz and
> the uncompressed vector is around 10MB. Now the problem is that because
> my Java thread runs with real time priority (which is the default on
> Vxworks) and deprive other threads, including non-Java ones, for this
> whole 50 sec period. This causes a watchdog thread to reset the system.
> I guess most of this delay is in GZipInputStream, as part of the
> un-gzipping process.
>
> My question is, is there a way to make ObjectInputStream.readObject()
> or any of the other connected streams (gzip and socket) yield the CPU
> to other threads once in a while? Or is there any other way to deal
> with the situation?
>
> Is the following a good solution?
>
> class MyGZipInputStream extends GZipInputStream {
> public int count = 0;
>
> public int read(byte b[], int off, int len) throws IOException {
> if(++count %10 == 0) // to avoid too many yields
> Thread.yield();
> return super.read(b, off,len);
> }
> }
>
>
> Thanks
> --kannan
>

Harish