Hi, i was also experiencing with the similar behavior. I adopted following approach
- used a distributed file system(in my case aws efs) and set the attribute "web.upload.dir", this way both the job manager have same location. - on the load balancer side(aws elb), i used "readiness probe" based on zookeeper entry for active jobmanager address, this way elb always point to the active job manager and if the active jobmanager changes then it automatically point to the new active jobmanager and as both are using the same location by configuring distributed file system so new active job is able to find the same jar. Regards, Ravi On Wed, Oct 16, 2019 at 1:15 AM Martin, Nick J [US] (IS) < nick.mar...@ngc.com> wrote: > I’m seeing that when I upload a jar through the rest API, it looks like > only the Jobmanager that received the upload request is aware of the newly > uploaded jar. That worked fine for me in older versions where all clients > were redirected to connect to the leader, but now that each Jobmanager > accepts requests, if I send a jar upload request, it could end up on any > one (and only one) of the Jobmanagers, not necessarily the leader. Further, > each Jobmanager responds to a GET request on the /jars endpoint with its > own local list of jars. If I try and use one of the Jar IDs from that > request, my next request may not go to the same Jobmanager (requests are > going through Docker and being load-balanced), and so the Jar ID isn’t > found on the new Jobmanager handling that request. > > > > > > > > >
