Temp folder on wrapper does not exist and synchronization bug in templatestorage #1294
Open
1 task done
Labels
s: confirmed
The described bug was reported multiple times and/or is reproduceable
t: bug
Something isn't working as intended
v: 4.X
This pull should be included in the 4.0 release
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: