Skip to content
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

Open
rmoff opened this issue Sep 22, 2014 · 6 comments
Open

init.d script doesn't cope with multiple instances on single server #11

rmoff opened this issue Sep 22, 2014 · 6 comments

Comments

@rmoff
Copy link

rmoff commented Sep 22, 2014

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?

@rmoff
Copy link
Author

rmoff commented Sep 22, 2014

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.

@stewartbryson
Copy link
Contributor

What is the actual problem Robin? It's because there are two instances running?

@rmoff
Copy link
Author

rmoff commented Sep 22, 2014

Additional complication -- one a single binary, multiple domain deployment, only a single NM is needed. Potentially this actually makes life easier

@rmoff
Copy link
Author

rmoff commented Sep 22, 2014

@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.
Whereas, we need to check that the AdminServer/ManagedServer/OPMN for the particular domain/instance combo is up or not.

@rmoff
Copy link
Author

rmoff commented Sep 22, 2014

f8172ae should fix this partially (i.e. for the WLS stuff, not OPMN), need to test it

@rmoff
Copy link
Author

rmoff commented Sep 22, 2014

looks OK to me, merged into develop. @stewartbryson give it a test?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants