search

galan / packtag

A JSP Taglib for delivering minified, combined and gzip-compressed resources (JavaScript and CSS).
Apache License 2.0
24 stars 13 forks source link

Pack file hash code is different on different Kubernetes pods #16

Open ol-vrobison opened 3 years ago

ol-vrobison commented 3 years ago

When deployed to a Kubernetes cluster, the name of combined.xxxxx.pack changes based on the pod it's running on. This means that if I have multiple pods for the same service and don't have sticky sessions enabled, I get 404 messages when trying to load a file that does not exist on one of the pods. E.g. pod 1 has combined.js.h840864473.pack, a refresh of the page can take me to a different pod to fetch the pack file, which returns 404, because the second pod was expecting a different pack file, e.g. combined.js.h-238451380.pack.

I understand that this project is not being maintained, but could you provide insight into why this happens? Is there a pseudo random element to how the hash for the file name is created? Is there a way to override it?

galan commented 3 years ago

Hi Victor, it has been a while since I have worked with pack:tag, but I think we are talking about two different issues here that come into play:

  1. The generated resource-name - This should stay the same, as long as the resources are unchanged, because the content of the file is hashed and used as name. The benefit was of course that the names only change when the content changes, and the client has another indicator to enforce a request of the updated resource. So hopefully that shouldn't do any impact on your issue.
  2. The on-demand generation - Assume the first user is requesting a resource on you newly started pod, it will generate the resource and cache it for future requests. However if the next request goes to a different pod, that is just started, then the resource hasn't been generated and will result in a 404.

So unfortunately there is state inside the library, that is preventing the usage without sticky sessions. However I think there was a cache-provider integration (with ehcache) that might be utilized to cache the resources in an external service, and it used some interface, that you can use to implement your own integration. Please check the documentation, maybe this might help you?