Program pauses initialization of object input stream in Java
When the debugger starts, the program pauses the initialization of object streams from the main server input streams. Below is the code:
public TFileReader(Client cli)throws Exception{
this.cli = cli;
fileSock = new Socket(cli.ServerIp(), cli.FilePort());
fobjIn = new ObjectInputStream(fileSock.getInputStream());
fobjOut = new ObjectOutputStream(fileSock.getOutputStream());
fobjOut.flush();
}
@Override
public void run(){
try{
System.out.println("file reader thread online");
fobjOut.writeObject(cli.Name());
fobjOut.flush();
String per = (String) fobjIn.readObject();
System.out.println(per+"video filing...");
if(!per.equals("OKF"))
{
throw new Exception("Error In retriving video.");
}
It stops at fobjIn
and does not jump to execution fobjOut
, although fobjIn
it jumps out of the breakpoint fobjIn
, it does not remove the breakpoint.
source to share
I would keep it simple like this
public TFileReader(Client cli) throws IOException {
this.cli = cli;
socket = new Socket(cli.ServerIp(), cli.FilePort());
out = new ObjectOutputStream(socket.getOutputStream());
out.flush();
in = new ObjectInputStream(socket.getInputStream());
}
public void writeObject(Object o) throw IOException {
out.writeObject(o);
out.reset();
out.flush();
}
public <T> T readObject() throw IOException {
return (T) in.readObject();
}
public void close() throws IOException {
in.close();
out.close();
socket.close();
}
source to share
The problem is that the ObjectInputStream is pre-reading the initialization data.
Java is the preferred solution. Create new ObjectInputStream blocks : Always initialize your ObjectOutputStream before initializing the ObjectInputStream, so that the handshake that the two use internally is initiated.
If you are out of control of all the code and cannot reorder, consider delaying OIS initialization until data is available (InputStream.available or mark / read / reset on the buffered stream, wrapping it, etc.).
source to share