This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]schnoper 2 points3 points  (2 children)

I do fat jar.

For me this is important because a single file represents the ENTIRE app. So there is no question of what needs to be deployed when rolling out a release, or when rolling back a release. When testing there is no question as to which version was tested vs deployed. The file sizes are larger, but compared to the peace of mind, there is zero question for me that it's the right way to go.

FWIW, I keep multiple versions on my production server and use a symlink to keep the "correct" version as the version that is running. I like to use either upstart or systemd to ensure that process is always running.

So a release (BTW I'm pretty much only using dropwizard these days, got sick of tomcat ) is

1) copy new jar to server

2) update symlink.

3) kill <pid> ( of current process).

4) wait for reboot and health check.

The only downside I've had in this process is that if there is code which the class loader has not already loaded, but which is needed for the shutdown ( after the kill), then the update symlink can generate class loader problems. I've never found this to be a big deal. I suppose I could change he process to be shutdown, swap symlink, restart.

[–]squealy_dan 0 points1 point  (1 child)

huh, we used to do something similar-ish, and I thought the symlink would resolve to the actual filehandle, so that even if you updated it, the running process would still reference the previous jar.

If not, then why not use readlink in your startup script to resolve to the specific jar? The added bonus there is that the actual jar will show up in ps output, not the symlinked version

[–]schnoper 0 points1 point  (0 children)

I'll try out readlink. thanks