Scenario:
We are having a scenario where there are two IS’s in organization (say IS1 and IS2). Both are clustered. Consider a scenario where there are two systems S1 as the source system and S2 as the destination system.
In a normal scenario messages sent from S1 reach S2 (lets say the key is workorder numbers) which are visible as a part of the contexid. (the package we are talking about, let it be called as P1. P1 is deployed on IS1 and IS2)
Everytime a message is sent from S1 to ESB (publish) or from ESB to S2(subscribe), it gets logged.
Whenever a message gets sent from S1 to ESB, an status acknowledgement is sent from ESB to S1.
Problem:
For some reason, IS1 was not working properly and the P1 was not enabled/not loaded on that IS1.
When I tried enabling/loading the package, it gave an error of being locked. Finally I just had to restart IS1, when the acknowledgements started coming from ESB to S1.
Can anyone explain why this happened? I have checked the logs to see something unusual but couldn’t find anything.
Note:
On the previous day I performed a deployment, where another set of packages were deployed. This too took lot of time and I had to rollback and redeploy.
What’s exactly the error message when you try to load/enable the package.
if some service under the package was locked by another user, you can’t load new version, you have to unlock the services. Hope this is the case.
Can you share the error from the server.log file during your deployment.
Best practice: Whenever you deploy packages from one IS to another IS make sure the packages (I mean elements under the package) are not locked by the user.
Thanks for your reply guys,
The way I deploy packages is by using a deployer.
How do we determine which services of a package are locked? OR
The package is locked
What sorted the problem was restarting the IS on which the package was locked…, just trying to understand why this behavour of IS when we have a clustered environment.