Stefan Neis
2014-08-07 08:29:41 UTC
Hi JCIFS support team,
while we are investigating thread behavior on our application server we
stumbled over dozens of Transport threads in blocking state. It turned
out that they are belonging to the jCIFS framework on connecting to a
not existing SMB resource. To reproduce this I wrote a little piece of
code:
for (int i = 0; i < 100; i++) {
try {
SmbFile folder = new
SmbFile("smb://192.168.100.77/test");
folder.exists();
}
catch (SmbException e) {
}
}
My observations with the tool VisualVM are as follows. On the call
exists() a thread named Transport1 is created. After 30 seconds a
SmbException occurs:
jcifs.smb.SmbException: Failed to connect: 0.0.0.0<00>/192.168.100.77
jcifs.util.transport.TransportException: Connection timeout
That is okay because the resource dos not exist. The next call to
exists() creates another Transport1 thread, while the first one is still
active for further 15 seconds. The second one is getting blocked by the
first thread. Because of the fact that the interval threads are getting
produced is shorter than the interval the threads are running, more and
more threads are in blocking state.
I tested it with jCIFS version 1.3.15 and 1.3.17.
The quick and dirty solution is to wait al least 15 seconds after every
thrown exception, but in my opinion it can't be the callers
responsibility to handle frameworks internal processes. And what if I
want to access the same resource from different places in my code?
Do you agree with this or am I doing something completely wrong?
while we are investigating thread behavior on our application server we
stumbled over dozens of Transport threads in blocking state. It turned
out that they are belonging to the jCIFS framework on connecting to a
not existing SMB resource. To reproduce this I wrote a little piece of
code:
for (int i = 0; i < 100; i++) {
try {
SmbFile folder = new
SmbFile("smb://192.168.100.77/test");
folder.exists();
}
catch (SmbException e) {
}
}
My observations with the tool VisualVM are as follows. On the call
exists() a thread named Transport1 is created. After 30 seconds a
SmbException occurs:
jcifs.smb.SmbException: Failed to connect: 0.0.0.0<00>/192.168.100.77
jcifs.util.transport.TransportException: Connection timeout
That is okay because the resource dos not exist. The next call to
exists() creates another Transport1 thread, while the first one is still
active for further 15 seconds. The second one is getting blocked by the
first thread. Because of the fact that the interval threads are getting
produced is shorter than the interval the threads are running, more and
more threads are in blocking state.
I tested it with jCIFS version 1.3.15 and 1.3.17.
The quick and dirty solution is to wait al least 15 seconds after every
thrown exception, but in my opinion it can't be the callers
responsibility to handle frameworks internal processes. And what if I
want to access the same resource from different places in my code?
Do you agree with this or am I doing something completely wrong?