Smack IBB FileTransfer issues

Hi,

I am working with Smack to provide a FileTransfer between clients in my application. I used the IBBStreams provided by IncomingFileTransfer and OutcomingFileTransfer to control those transfers and to know the status of a transfer as the ‘‘Observer’’ pattern states. The thread that controls the transfer works like the TransferThreads.

When testing the file transfer with a receiver side fail, the sender detects an error and could react as expected. But when the sender fails, the receiver is never notified. This happens with IBBInputStream since it could never exit the ‘‘loadBufferWait()’’ method and there is no timeout to exit the wait loop. Since I used a external thread to monitor for a timeout, this was not a problem to me: I try to close the stream so the read could return. Looking at the code, read() and close() are synchronized, and with read() holding the lock of this object, a could not close the stream, and also there is no logic associated with the close that would release the read() invokation (this is the expect behavior of a InputStream in java).

I would like to know if someone has the same problem, and if so, how can I fix it? What I did to fix this at smack and make it consistent with java default InputStream behaviour was to synchronize only the critical block of close and test in the while loop of loadBuffer if I the stream is closed:

New while loop block of loadBufferWait() at IBBTransferNegotiator.IBBInputStream:

while (mess == null) {

if (isDone) {

mess = (Message) dataCollector.pollResult();

if (mess == null) {

return false;

}

}

else {

mess = (Message) dataCollector.nextResult(1000);

if (isClosed) {

throw new IOException(“Reading a closed stream.”);

}

}

}

And IBBTransferNegotiator.IBBInputStream.close():

public void close() throws IOException {

if (isClosed) {

return;

}

isClosed = true;

synchronized (this) {

cleanup();

if (isEOF) {

sendCloseConfirmation();

}

else if (lastMess != null) {

sendCancelMessage(lastMess);

}

}

}

All seens to work with the Socks5Stream, since when the sender fails, a read outputs -1.

Thanks,

Matheus G.