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

WFLY-3624 ConsistentHashFactory needs to be configurable via XML #6531

Merged
merged 1 commit into from Aug 5, 2014
Merged

WFLY-3624 ConsistentHashFactory needs to be configurable via XML #6531

merged 1 commit into from Aug 5, 2014

Conversation

pferraro
Copy link
Contributor

https://issues.jboss.org/browse/WFLY-3624

Also add ability to configure capacity-factor.

@wildfly-ci
Copy link

Build 4320 is now running using a merge of 3a02de6

@wildfly-ci
Copy link

Build 4320 outcome was SUCCESS using a merge of 3a02de6
Summary: Tests passed: 3086, ignored: 231 Build time: 1:19:04

@bstansberry
Copy link
Contributor

Looks good.

@bstansberry
Copy link
Contributor

Twice now this has failed on the Windows tests of master-ignore. The build log for the latest is at http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=18938&buildTypeId=WF_MasterIgnoreWindows&tab=buildLog#_focus=17503

The problem begins here:

[20:53:06][org.wildfly:wildfly-ts-integ-clust] Running org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulFailoverTestCase

No result for that test is ever published and roughly 20 mins later the run continues on, but totally fubar.

Same thing at 19:18:39 on http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=18933&buildTypeId=WF_MasterIgnoreWindows&tab=buildLog#_focus=46

@pferraro
Copy link
Contributor Author

Both runs seem to fail in the same spot for the same reason, due to a management connection being severed after 2 minutes following an undeploy operation. In both cases, jgroups channels and infinispan caches were all shutdown successfully, as are all EJB deployments. All indication are that the failures are due to the environment or the test framework - not the test nor the functionality being tested.

2014-07-29 19:21:11,290 INFO [org.jboss.as.repository](management-handler-thread - 3) WFLYDR0002: Content removed from location C:\BuildAgent\work\b145776b46e82d98\testsuite\integration\clust\target\jbossas-clustering-SYNC-tcp-0\standalone\data\content\25\372d77314699f2ee7a1c437ff5771730155f79\content
2014-07-29 19:21:11,290 INFO [org.jboss.as.server](management-handler-thread - 3) WFLYSRV0009: Undeployed "stateful-failover.war" (runtime-name: "stateful-failover.war")
2014-07-29 21:22:54,596 ERROR [org.jboss.remoting.remote.connection](XNIO-1 I/O-1) JBREM000200: Remote connection failed: java.io.IOException: An existing connection was forcibly closed by the remote host
2014-07-29 21:22:54,600 INFO [org.jboss.as.protocol](XNIO-1 I/O-1) WFLYPRT0057: cancelled task by interrupting thread Thread[management-handler-thread - 1,5,management-handler-thread]
2014-07-29 21:23:03,146 ERROR [org.jboss.remoting.remote.connection](default I/O-2) JBREM000200: Remote connection failed: java.io.IOException: An existing connection was forcibly closed by the remote host
2014-07-29 21:23:03,160 ERROR [org.jboss.remoting.remote.connection](default I/O-2) JBREM000200: Remote connection failed: java.io.IOException: An existing connection was forcibly closed by the remote host
2014-07-29 21:23:03,163 ERROR [org.jboss.remoting.remote.connection](default I/O-1) JBREM000200: Remote connection failed: java.io.IOException: An existing connection was forcibly closed by the remote host

@wildfly-ci
Copy link

Build 4370 is now running using a merge of f1bafbd

@wildfly-ci
Copy link

Build 4370 outcome was SUCCESS using a merge of f1bafbd
Summary: Tests passed: 3092, ignored: 231 Build time: 1:16:57

@bstansberry
Copy link
Contributor

After I pushed #6541 yesterday I tried this one again on master-ignore and it failed again, although at a glance the failure doesn't seem exactly the same:

http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=18980&tab=buildResultsDiv&buildTypeId=WF_MasterIgnoreWindows

Someone just re-ran that job, which failed again:

http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=19046&tab=buildResultsDiv&buildTypeId=WF_MasterIgnoreWindows

I see there was an update to this branch. I don't know if that happened before or after my push to master-ignore.

Whether or not this PR is related to these failures, I don't see how we can merge new features when the clustering testsuite can't run reliably.

@pferraro
Copy link
Contributor Author

OK - WFLY-3695 should (hopefully) fix the plague of the "unable to create new native thread" OOME

@wildfly-ci
Copy link

Build 4379 is now running using a merge of ea7a23f

@wildfly-ci
Copy link

Build 4379 outcome was SUCCESS using a merge of ea7a23f
Summary: Tests passed: 3092, ignored: 231 Build time: 1:15:00

@wildfly-ci
Copy link

Build 4392 is now running using a merge of e4b491a

@wildfly-ci
Copy link

Build 4392 outcome was FAILURE using a merge of e4b491a
Summary: Tests failed: 1 (1 new), passed: 3091, ignored: 231, muted: 1 Build time: 1:16:39

Build problems:

Failed tests detected

javax.ejb.EJBTransactionRolledbackException: WFLYJPA0030: Found extended persistence context in SFSB invocation call stack but that cannot be used because the transaction already has a transactional context associated with it.  This can be avoided by changing application code, either eliminate the extended persistence context or the transactional context.  See JPA spec 2.0 section 7.6.3.1.  Scoped persistence unit name=passivation-test.jar#main, persistence context already in transaction =ExtendedEntityManager [passivation-test.jar#main], extended persistence context =ExtendedEntityManager [passivation-test.jar#main].
javax.ejb.EJBTransactionRolledbackException: WFLYJPA0030: Found extended persistence context in SFSB invocation call stack but that cannot be used because the transaction already has a transactional context associated with it.  This can be avoided by changing application code, either eliminate the extended persistence context or the transactional context.  See JPA spec 2.0 section 7.6.3.1.  Scoped persistence unit name=passivation-test.jar#main, persistence context already in transaction =ExtendedEntityManager [passivation-test.jar#main], extended persistence context =ExtendedEntityManager [passivation-test.jar#main].
    at org.jboss.as.jpa.container.ExtendedEntityManager.internalAssociateWithJtaTx(ExtendedEntityManager.java:136)
    at org.jboss.as.jpa.container.SFSBCallStack.pushCall(SFSBCallStack.java:157)
    at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:54)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:127)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
    at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46)
    at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
    at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:252)
    at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:343)
    at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:240)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
    at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(Nam ...
org.junit.ComparisonFailure: expected:<[]OVERRIDDEN> but was:<[NON ]OVERRIDDEN>
org.junit.ComparisonFailure: expected:<[]OVERRIDDEN> but was:<[NON ]OVERRIDDEN>
    at org.junit.Assert.assertEquals(Assert.java:115)
    at org.junit.Assert.assertEquals(Assert.java:144)
    at org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase.testSimpleOverrideWithRedeployAffected(DeploymentOverlayCLITestCase.java:406)

Failed tests

org.jboss.as.test.integration.management.cli.DeploymentOverlayCLITestCase.testSimpleOverrideWithRedeployAffected: org.junit.ComparisonFailure: expected:<[]OVERRIDDEN> but was:<[NON ]OVERRIDDEN>
    at org.junit.Assert.assertEquals(Assert.java:115)
    at org.junit.Assert.assertEquals(Assert.java:144)

@pferraro
Copy link
Contributor Author

pferraro commented Aug 1, 2014

Unrelated failure. Retest this please.

@wildfly-ci
Copy link

Build 4397 is now running using a merge of e4b491a

@wildfly-ci
Copy link

Build 4397 outcome was SUCCESS using a merge of e4b491a
Summary: Tests passed: 3092, ignored: 231 Build time: 1:18:28

@pferraro
Copy link
Contributor Author

pferraro commented Aug 4, 2014

Are there any remaining failures that are blocking this PR from being merged?

bstansberry added a commit that referenced this pull request Aug 5, 2014
@bstansberry
Merge pull request #6531 from pferraro/hash
94c039b 
WFLY-3624 ConsistentHashFactory needs to be configurable via XML
@bstansberry bstansberry merged commit 94c039b into wildfly:master Aug 5, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
4 participants
@pferraro @wildfly-ci @bstansberry @n1hility