-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
init.d script doesn't cope with multiple instances on single server #11
Comments
Problem was that the "fingerprint" was not specific enough. For WLS this is easy enough to fix by including the domain in the grep string. However for opmn the process details don't include the path. Instead, we should check if OPMN is listening and also parse opmnctl status to determine if everything's running or not. |
What is the actual problem Robin? It's because there are two instances running? |
Additional complication -- one a single binary, multiple domain deployment, only a single NM is needed. Potentially this actually makes life easier |
@stewartbryson with one instance running, the script called to fire up the second instance does its pgrep and sees that there is a "AdminServer" process running, matching the FMW_HOME, and concludes that that must be its own AdminServer, so then goes on to start up the managed server etc. |
f8172ae should fix this partially (i.e. for the WLS stuff, not OPMN), need to test it |
looks OK to me, merged into develop. @stewartbryson give it a test? |
c.f. SampleApp v406 with both instances running. Get confused about ports etc. Needs to be more specific in grepping for paths associated with processes maybe?
The text was updated successfully, but these errors were encountered: