K
kannan123
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
(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