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.

Sign up for GitHub

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

Jump to bottom

Redeploying war/ear on cluster fails #492

Closed
dorpsidioot opened this issue Oct 26, 2015 · 6 comments
Closed

Redeploying war/ear on cluster fails #492

dorpsidioot opened this issue Oct 26, 2015 · 6 comments
Milestone
Payara Server 4.1...

Comments

@dorpsidioot
Copy link

When deploying an application(war or ear) for the second time on a cluster, the deployment fails with messages that certain parts already exist (virtual server already has a xxx module loaded at...) or are greeted with the 'Error linking in security policy - Inconsistent module state' message in the cluster's logs.

It happens with both simple projects and big projects. Checking the force redeploy checkbox does nothing. We have to restart the cluster instances to alleviate the issue, which kind of beats the purpose of having a cluster. We encounter the issue both at the instances -> applications -> undeploy and also when undeploying via the applications of the DAS.

What's strange is that we don't even get undeployment messages in the nodes when undeploying an application and timers seem to continue running.
@dorpsidioot dorpsidioot changed the title Deploying or redeploying war/ear on cluster fails Redeploying war/ear on cluster fails Oct 26, 2015
@dorpsidioot
Copy link
Author

Disabling application works, re-enabling them works as well. Disabling application and then undeploy/deploy works.

It's only when undeploying a running application, the application still keeps on running on the nodes.

@dmatej
Copy link
Contributor

dmatej commented Oct 29, 2015

Have you tried also version 4.1.1.154? It seems better, we had the same problem in 4.1.152 ...

@dorpsidioot
Copy link
Author

Didn't have the issue in 4.1.153, but there we encountered issues with redeploying after a certain time, so upgraded to 4.1.154 and then this issue appeared.

@dorpsidioot dorpsidioot mentioned this issue Nov 4, 2015
Closed
@smillidge
Copy link
Contributor

OK thanks we'll investigate.

@smillidge smillidge added this to the Payara Server 4.1.161 milestone Nov 21, 2015
@dorpsidioot
Copy link
Author

Will see if we can deploy a snapshot version to our cluster for testing. Is it possible to simply copy the domain.xml from the current to new version to upgrade or is there a preferred upgrade path?

@smillidge
Copy link
Contributor

I would wait at the moment as our Jenkins is being temperamental so the pull request hasn't been incorporated yet.

Pandrex247 added a commit that referenced this issue Nov 30, 2015
@Pandrex247
Merge pull request #533 from smillidge/PAYARA-511
ce67139 
PAYARA-511 fixes #492
mulderbaba pushed a commit to mulderbaba/Payara that referenced this issue Dec 2, 2015
PAYARA-511 fixes payara#492 disable command was not executing correct…
f5f0dc8 
…ly on a cluster due to not matching the cluster target name with the server name
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
Payara Server 4.1.161
Development

No branches or pull requests
3 participants
@dmatej @smillidge @dorpsidioot