I know that it is highly recommend to restart app process after fixpack or upgrade so that agents also is upgraded.
However for the JVM and .Net agents the old agents works fine and gets updated seamlessly when the app is restarted next time.
For the EWS we see that the agent update is not that easy, we have to coordinate a primary agent restart and then the web server process restart to get the secondary updated. Else we see the error 'Shared memory version mismatch'.
My question is old agents works with new collector why cannot the old web server secondary agent work with the new primary agent or wise versa (newer secondary can work with old primary). If this works then we could follow the normal app recycle and at a later point restart the primary agent from the server console.
Primary and secondary agents are both form dynatrace so can't we get it work with different versions?
Solved! Go to Solution.
I like the idea,
Bottom line is we need some solution because even for a small minor fix pack roll-out we have to plan an application downtime. Web servers are internet facing components less the change the better.
I still wonder why these two agents are complaining on even a minor version difference. Does this has to be that tightly coupled?
Could there be a better solution in which secondary and primary can be restarted and upgraded in any order? at-least for minor version changes.
The primary and secondary agent share memory. I think we force you to update both agents to ensure that both agents are able to understand how the shared memory is structured. If for any reason the memory is not understood the same way by both agents, this would cause one of them to crash.
Sreerag, you may want to post this idea as a request for enhancement (Idea section of the forum).
just as a heads-up: this also caused me some headaches in the past, already. it might have made sense in the past when the shared memory format was changed a lot, but currently it's causing mostly troubles with updates/upgrades.
good news is however, that we already have a solution and far better approach to this primary-secondary concept that we're working on. this will make it most probably into one of the next releases.
Hello @Munawar S.
The most common root cause for this issue is that primary agents are not restarted after an update has been installed. The secondary agents will receive an update when a workprocess is restarted. The webserver primary agent however need to be restarted manually to apply the update. If the primary agent is not restarted, the secondary agents can have a new version than the primary agent, therefore causing this problem.
Have a look on the below documentation.