I have a desktop app with install4j auto-updates (checked at app startup). I want to do a phased rollout of the updates.
For this I am thinking of having Apache Load Balancer serve an updated version of updates.xml to a subset of my users. The problems I am seeing:
If the response to a request of updates.xml sets a cookie, will the request to the media parts include that cookie? The cookie is needed to prevent loss of stickyness, as explained on the section "Details on load balancer stickyness" of the provided link. I don't want a client app that recieves the updated updates.xml then have an 404 when fetching a mediapart because it's request being redirected to the "old" server.
If I setup the load balancing to redirect 10% of my traffic to the new updates.xml, this doesn't mean I will achieve 10% of my users getting the updated version. The actual percentage will have no correlation. This is because even up-to-date apps will still check updates.xml at startup, counting towards the total traffic. I guess this is ok as long as I don't need precise figures but just want to avoid a big bang deployment. But is there a better approach?
Edit
I implemnted load balancing on the deployment folder. The workflow is like this:
If the response to a request of updates.xml sets a cookie, will the request to the media parts include that cookie?
No, cookies are not managed by install4j, you can only set a cookie in the "Request headers" property of actions like the "Check for update" and "Download file" actions.
You would have to first add a "HTTP request" action to some resource on the server and configure its "Variable name for response headers" property to extract the cookie. The "HTTP request method" property can be set to "HEAD" so you only get the headers. From that variable (a map instance), you can get the cookie variable and save it to another installer variable. This logic can be done in a "Run script" action.