Frage

We are using Future with a timeout to accomplish a task. We get a TimeOutException when time limit exceeds. From the behavior of thread dump, I realize that underlying thread continues.

Is it the case? How does it take care of multiple threads roaming around? What if no IOException is thrown for the thread which was removed from the pool?

If this is true, what is the way to kill underlying thread. It keeps on waiting for an external IO in my case.

A part of thread dump:

Thread 29587: (state = IN_NATIVE)
 - java.net.SocketInputStream.socketRead0(java.io.FileDescriptor, byte[], int, int, int) @bci=0 (Compiled frame; information may be imprecise)
 - java.net.SocketInputStream.read(byte[], int, int) @bci=84, line=129 (Compiled frame)
 - java.io.BufferedInputStream.fill() @bci=175, line=218 (Compiled frame)
 - java.io.BufferedInputStream.read1(byte[], int, int) @bci=44, line=258 (Compiled frame)
 - java.io.BufferedInputStream.read(byte[], int, int) @bci=49, line=317 (Compiled frame)
 - sun.net.www.MeteredStream.read(byte[], int, int) @bci=16, line=116 (Compiled frame)
 - java.io.FilterInputStream.read(byte[], int, int) @bci=7, line=116 (Compiled frame)
 - sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(byte[], int, int) @bci=4, line=2672 (Compiled frame)
 - javax.imageio.stream.FileCacheImageInputStream.readUntil(long) @bci=64, line=121 (Compiled frame)
 - javax.imageio.stream.FileCacheImageInputStream.read(byte[], int, int) @bci=69, line=167 (Compiled frame)
 - com.sun.imageio.plugins.jpeg.JPEGImageReader.readImageHeader(long, boolean, boolean) @bci=0 (Compiled frame)
 - com.sun.imageio.plugins.jpeg.JPEGImageReader.readNativeHeader(boolean) @bci=12, line=532 (Compiled frame)
 - com.sun.imageio.plugins.jpeg.JPEGImageReader.checkTablesOnly() @bci=92, line=277 (Compiled frame)
 - com.sun.imageio.plugins.jpeg.JPEGImageReader.gotoImage(int) @bci=41, line=409 (Compiled frame)
 - com.sun.imageio.plugins.jpeg.JPEGImageReader.readHeader(int, boolean) @bci=2, line=525 (Compiled frame)
 - com.sun.imageio.plugins.jpeg.JPEGImageReader.readInternal(int, javax.imageio.ImageReadParam, boolean) @bci=3, line=968 (Compiled frame)
 - com.sun.imageio.plugins.jpeg.JPEGImageReader.read(int, javax.imageio.ImageReadParam) @bci=8, line=948 (Compiled frame)
 - javax.imageio.ImageIO.read(javax.imageio.stream.ImageInputStream) @bci=55, line=1422 (Compiled frame)
 - javax.imageio.ImageIO.read(java.net.URL) @bci=42, line=1374 (Compiled frame)

Once TimeOutException occurs (for any task in the loop), we cancel the tasks like this:

for(Entry<Requests, Future<?>> futureTask : futureTasks.entrySet())
                {
                    Future<?> future = futureTask.getValue();
                    if(!future.isDone() || future.isCancelled())
                    {
                        future.cancel(true);
                        }
                }

Shouldn't it solve the problem?

Please advice.

Thanks in advance.

War es hilfreich?

Lösung

Yes, it's the case that your thread continues and executed task is unaffected. TimeoutException indicates that you didn't get the result in the appropriate time.

If you want to interrupt underlying thread you can handle the exception and use cancel(true) method from the used implementation of Future.

EDIT

I missed the case that your thread is waiting on a blocking I/O as your stack trace explains. Thread.interrupt() which is called from future.cancel(true) won't help in this case.

The common pattern in this situtation is to close underlying input stream. I'm not very familiar with javax.imageio package but there is an overloaded method on ImageIO which accepts the InputStream. You might want to store it somewhere and later close it on timeout.

It will call close() on SocketInputStream which in its turn will call close() method of underlying Socket which is waiting for blocking read to complete. An executing thread which is blocked in an I/O operation (as per your trace) upon this socket will stop waiting for EOF with SocketException.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top