How does Getdown handle files that were deleted on server

[Daniel Ferber]

Hi,

My .jar files that are deployed to the server are named with a suffix that identifies the version. For example:

app/br-com-xyz-base/br-com- xyz-base__V1.12.0-3541.jar

On deploying a new version to the server, this file is deleted and replaced by another version:

app/br-com-xyz-base/br-com- xyz-base__V1.12.1-3553.jar

I noticed that:

1) O starting the application again, getdown displays error messages that the old file ( app/br-com-xyz-base/br-com- xyz-base__V1.12.0-3541.jar) was not found. And fails to start the application. The user has to try launching the application again.

2) The local directory keep a copy of all versions of the file, it does not delete the versions that are not used anymore.

Would be there be advices?

I am not (yet) declaring the verion integer number in the getdown.txt file.

One may ask why files have the version number in the suffix: I am reusing a legacy jnlp build and just wrapping it as a getdown application. I dont want to change the existing build yet, there are still some clients calling the application using jnlp and we have to move gradually away from jnlp.

Best regards,

Daniel Felix Ferber

[Daniel Ferber]

After reading the launch.log file, I would suppose that:

When I update the application on the server:

Getdown realizes that the local getdown.txt does not match the remote one. Therefore, it redownloads the getdown.txt as expected. However, the launcher keeps using the jar references from the old getdown.txt file instead of the newly downloaded one. Therefore, it tries do validate the old list of .jar file references, and some of the files may not exist anymore.

Shouldn't getdown use a kind of upgrade path if getdown.txt has changed? Using the current (newer) version of getdown.txt?

Best regards,

Daniel Felix Ferber

[Michael Bayne]

I'm pretty sure this is not the problem. Getdown rebuilds all of its internal configuration state after updating the getdown.txt file before proceeding, so if getdown.txt changed, it should use the new jar files from the new getdown.txt after updating. This certainly works in some circumstances because a common usage pattern is to ship an app with a stub getdown.txt that contains nothing but an appbase. Getdown will then download the updated getdown.txt, reinitialize itself and then download the real app. If it was still using the stub it would think the app had no jar files, etc.

That's not to say there isn't potential for some bug, but the expected behavior when a getdown.txt is changed is that Getdown will use the new configuration immediately after updating.

--
You received this message because you are subscribed to the Google Groups "OOO Libs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ooo-libs+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ooo-libs/70665335-29d8-47e6-a2df-97b601dbbb40n%40googlegroups.com.

--

-- m...@samskivert.com

[Michael Bayne]

On Fri, Nov 20, 2020 at 5:28 AM Daniel Ferber <dff...@gmail.com> wrote:

2) The local directory keep a copy of all versions of the file, it does not delete the versions that are not used anymore.

This is also expected behavior. Getdown never deletes anything. If your app changes jar files, you have to manually delete the old ones. We never needed the ability to delete old jar files and no one has ever submitted a patch that enables Getdown to diff between old and new getdown.txt configurations and determine which old files to delete. So it's never been supported.

-- m...@samskivert.com

[Daniel Ferber]

Hi, after using getdown for some months, I feel more confident about the behavior I described on my first message.

 

Getdown never deletes a downloaded file and it makes sense. And it would be no issue keeping all those old files.

 

But I really noticed that that, using unversioned mode, when a new getdown.txt gets downloaded, it still assumes the list of resouces and jars from the previous getdown.txt.

For the files that kept the original name, it correctly validates the file checksum and downloads them again if the checksum has changed. However, it tries to download old files that existed in the old getdown.txt (and do not exist anymore on the server and are not mentioned anymore in the new getdown.txt). After a number of retries, getdown stops and shows an error message to the user.

 

When the user tries to start the application again, then getdown reads the correct (new getdown.txt) and checks the correct files (as described in the new getdown.txt).

 

It least, I could observe it consistently from the logs. I hope to have an opportunity to get further details.

 

This issue does not happen on versioned mode.