Closed laeubi closed 11 months ago
This is possibly because the same DiskShare
instance is shared between different callers (and closed by one of them) because of caching in TreeConnectTable
when obtaining the share from Session#connectShare
.
@dkocher would it be possible to make the cache a ThreadLocal then? the Share implments AutoCloseable
so I assume it should probably return the instance to the cache unclosed then instead of really closing it until the usecount == 0 ?
I think its quite impossible to control what others do with the disk share and when close is actually called...
@laeubi I am not the maintainer of the library but came across the same issue and worked around it using synchronization ^1
I think one problem is that still code can bypass that synchronization, what I'm wondering (maybe you have some experience) if then probably one better never close the share (and wait for the JVM exit instead?
I think one problem is that still code can bypass that synchronization, what I'm wondering (maybe you have some experience) if then probably one better never close the share (and wait for the JVM exit instead?
It is probably intended by the library that callers use a single long living share. Not sure yet if it is a (performance) issue to have the disk share short lived and open and close frequently.
Actually it is even intended by the SMB spec... That was why it was built as such
Actually it is even intended by the SMB spec... That was why it was built as such
You mean to open the session and never close it again? Can you explain what the AutoClosable
was chosen here? Because most IDEs will complain if you not close an AutoClosable
:-\
So to summarize, one would connect a share and then never touch that would be fine?
I have now tested without closing the share and it seems to work quite fine, so I think the issue can be closed, maybe one should enhance the javadoc that a DiskShare (even though it implements AutoClosable
) should usually not be closed unless the application shut down or it is made sure the share is not needed anymore.
I'm using the SMBJ lib for quite a while but getting spurious errors, from the logfile it is like this:
so for me it seems the usercode is unlucky getting in the way while a reconnect is happening on the session.
It would be great if this can be detected that a reconnect is currently performed and the
Share.send
method is blocking until the reconnect is finished (either success or failed).