New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Temp folder on wrapper does not exist and synchronization bug in templatestorage #1294
Comments
Thanks for the issue. If you want to create a PR we would appreciate that |
I have been investigating a little bit and it seems this issue occurs because there are multiple PacketDispatcher threads on the wrapper. Everything is sent in the right order from the node, but the channelmessage queryresult gets read on one packetdispatcher while a second packetdispatcher is still writing to the temporary file. The core issue is: The requesting ChannelMessage gets answered before writing to the file has finished There are multiple options to solve this: The future from #transferChunkedData may only return after the receiver has finished receiving the file, not the sender sending. The other option is for the receiver to cache the request in form of a future (similar to how ChannelMessage Queries work). The receiver then, after receiving the queryResult has to wait for the cached request. Just wanted to ask if there is a preferred way of doing this before coding it and the PR getting rejected for sth. |
Stacktrace
Actions to reproduce
Try to open a template as a ZipInputStream from a wrapper
templateStorageProvider.localTemplateStorage().openZipInputStreamAsync(ServiceTemplate.parse("proxy/default"))
CloudNet version
[19.08 22:10:36.283] INFO:
[19.08 22:10:36.283] INFO: CloudNet Blizzard 4.0.0-RC9 f6ca4c3
[19.08 22:10:36.283] INFO: Discord: https://discord.cloudnetservice.eu/
[19.08 22:10:36.283] INFO:
[19.08 22:10:36.284] INFO: ClusterId: 0cac9bb5--45dd--5d9b389b1b0f
[19.08 22:10:36.284] INFO: NodeId: Node-768d8079
[19.08 22:10:36.284] INFO: Head-NodeId: Node-768d8079
[19.08 22:10:36.284] INFO: CPU usage: (P/S) .23/7.21/100%
[19.08 22:10:36.284] INFO: Node services memory allocation (U/R/M): 2524/2524/6000 MB
[19.08 22:10:36.284] INFO: Threads: 50
[19.08 22:10:36.284] INFO: Heap usage: 40/256MB
[19.08 22:10:36.284] INFO: JVM: Eclipse Adoptium 17 (OpenJDK 64-Bit Server VM 17.0.6+10)
[19.08 22:10:36.285] INFO: Update Repo: CloudNetService/launchermeta, Update Branch: beta (development mode)
[19.08 22:10:36.285] INFO:
Other
Template might need to be a few MB in size, very small sizes might not trigger the synchronization bug, but for larger sizes it is triggered for sure and the first Exception gets called.
The second exception is a bug where the temp directory doesn't exist in the wrapper.
The two exceptions are in the same bug report because they go hand in hand here and here.
The synchronization bug I mean is that the ChannelMessage query returns before the upload/download has finished and the file has been released.
The first exception is before the second in the console. Order is kind of important here...
I need this kind of urgently which is why I would offer to make a PR.
Adding something like mkdirs for the temp folder should suffice for stacktrace 2.
For stacktrace 1 I'd probably redirect the future (after the received query use a future[callback?] from the DefaultFileChunkedPacketHandler. )
Another option I though of (to make it more future-proof) is some sort of confirmation from the receiving end of DefaultFileChunkedPacketSender.
Let me know if I should do this, or if the TemplateStorage API not working is enough to get this to the top of your guys' todo-list :)
Issue uniqueness
The text was updated successfully, but these errors were encountered: