Closed phatt-millips closed 3 years ago
Try to upgrade to the latest org.codelibs:jcifs:2.1.25
: https://github.com/codelibs/jcifs/releases.
I don't think that we can do something on the matter from Spring Integration code base since we fully delegate to the jcifs
API.
That does seem to be the issue. I added the org.codelibs:jcifs:2.1.25
dependency and it shuts down gracefully but strangely enough it now leaves off one document in the zip file
Sure! But still: isn't that what would better to discuss with jcifs
library not here?
Please, consider to contact with their developers or ask the question on StackOverflow.
Our knowledge here is limited with what internals of that library.
Thanks for understanding.
That's fine. I'll see if I can reach out to them. Thanks!
I have a service that is using spring-integration-smb 1.2.0 to upload zipped documents to a file share. It is also running in Kubernetes. After some investigation, we found that the service is uploading corrupt files as the service is being scaled down. The simple solution was to update to 1.2.1 which partially fixed the issue only now the service is submitting half of the data. More specifically, if the zipped file that's being uploaded contains 10 images it may only upload 5 or 6.
Here is a sample of the client we are using to upload
So in its current form, it is actually better for us not to update to 1.2.1 because this service using Apache Camel routes to route messages from a message broker to the SmbUploadClient. With 1.2.0 it will throw an exception when shutting down mid-upload and not dequeue the message on the broker triggering a retry on a different instance. While 1.2.1 will dequeue the message, not retry the message, and still break things downstream. Any help here would be greatly appreciated.
Steps to repro:
Please let me know if you have different results on the repro steps.