[JBoss JIRA] (JGRP-1993) ENCRYPTAsymmetricTest fails on IBM jdk 1.8
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1993?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1993:
--------------------------------
Richard, do you have a box with IBM JDK 8 on which I can reproduce this ?
> ENCRYPTAsymmetricTest fails on IBM jdk 1.8
> ------------------------------------------
>
> Key: JGRP-1993
> URL: https://issues.jboss.org/browse/JGRP-1993
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.6
> Environment: IBM jdk 1.8
> Reporter: Richard Janík
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.8
>
>
> org.jgroups.protocols.ENCRYPTAsymmetricTest.testKeyChangesDuringKeyServerChange fails on IBM jdk 1.8 (JGroups 3.6.6.Final):
> {code}
> Error Message
> expected [javax.crypto.spec.SecretKeySpec@174de] but found [com.ibm.crypto.provider.AESSecretKey@e562eaa8]
> Stacktrace
> java.lang.AssertionError
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:496)
> at org.testng.Assert.assertEquals(Assert.java:125)
> at org.testng.Assert.assertEquals(Assert.java:167)
> at org.jgroups.protocols.ENCRYPTAsymmetricTest.testKeyChangesDuringKeyServerChange(ENCRYPTAsymmetricTest.java:404)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:816)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1124)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
> at org.testng.TestRunner.privateRun(TestRunner.java:774)
> at org.testng.TestRunner.run(TestRunner.java:624)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:359)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:354)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:312)
> at org.testng.SuiteRunner.run(SuiteRunner.java:261)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1215)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
> at org.testng.TestNG.run(TestNG.java:1048)
> at org.testng.TestNG.privateMain(TestNG.java:1355)
> at org.testng.TestNG.main(TestNG.java:1324)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFCORE-591) revertReloadRequired() throws a NPE is reloadRequired has not been called
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-591?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-591:
------------------------------------------------
Romain Pelisse <rpelisse(a)redhat.com> changed the Status of [bug 1294591|https://bugzilla.redhat.com/show_bug.cgi?id=1294591] from VERIFIED to ASSIGNED
> revertReloadRequired() throws a NPE is reloadRequired has not been called
> -------------------------------------------------------------------------
>
> Key: WFCORE-591
> URL: https://issues.jboss.org/browse/WFCORE-591
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha19
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 1.0.0.Beta1
>
>
> If an operation step handler calls org.jboss.as.controller.OperationContext#revertReloadRequired() when org.jboss.as.controller.OperationContext#reloadRequired() has not been called, it throws a NPE:
> {noformat}
> java.lang.NullPointerException
> at org.jboss.as.controller.ControlledProcessState.revertReloadRequired(ControlledProcessState.java:181)
> at org.jboss.as.controller.AbstractOperationContext.revertReloadRequired(AbstractOperationContext.java:1037)
> at org.jboss.as.controller.test.RevertReloadRequiredTestCase$TestResourceAddHandler.rollbackRuntime(RevertReloadRequiredTestCase.java:98)
> at org.jboss.as.controller.AbstractAddStepHandler$1$1.handleRollback(AbstractAddStepHandler.java:133)
> at org.jboss.as.controller.AbstractOperationContext$RollbackDelegatingResultHandler.handleResult(AbstractOperationContext.java:1419)
> at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1385)
> at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1367)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1323)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1283)
> at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1172)
> at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:929)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:877)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:601)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1182)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:362)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:205)
> {noformat}
> The NPE is caused by this.activeStep.restartStamp field which is set only when reloadRequired() (or restartRequired()) is called.
> My OSH may call reloadRequired() or not depending on some runtime state and I could add some logic to make sure I call
> I can fix my handle to check that I call context.revertReloadRequired() only I had previously called reloadRequired () first.
> However, in order to make the OperationContext more robust, I think that the revertReloadRequired() method should instead be a no-op if there is no reload required.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFCORE-1257) support query filter implementation in MBeanServerConnection
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1257?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration updated WFCORE-1257:
--------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1294010
Bugzilla Update: Perform
> support query filter implementation in MBeanServerConnection
> ------------------------------------------------------------
>
> Key: WFCORE-1257
> URL: https://issues.jboss.org/browse/WFCORE-1257
> Project: WildFly Core
> Issue Type: Feature Request
> Components: JMX
> Affects Versions: 2.0.5.Final
> Reporter: Chao Wang
>
> There is no implementation for query filter in MBeanServerConnection, marked as TODO
> {code:title=ModelControllerMBeanHelper.java|borderStyle=solid}
> Set<ObjectName> queryNames(final ObjectName name, final QueryExp query) {
> return new RootResourceIterator<Set<ObjectName>>(accessControlUtil, getRootResourceAndRegistration().getResource(),
> new ObjectNameMatchResourceAction<Set<ObjectName>>(name) {
> Set<ObjectName> set = new HashSet<ObjectName>();
> @Override
> public boolean onResource(ObjectName resourceName) {
> if (name == null || name.apply(resourceName)) {
> //TODO check query
> set.add(resourceName);
> }
> return true;
> }
> @Override
> public Set<ObjectName> getResult() {
> if (set.size() == 1 && set.contains(ModelControllerMBeanHelper.createRootObjectName(domain))) {
> return Collections.emptySet();
> }
> return set;
> }
> }).iterate();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFCORE-1257) support query filter implementation in MBeanServerConnection
by Chao Wang (JIRA)
Chao Wang created WFCORE-1257:
---------------------------------
Summary: support query filter implementation in MBeanServerConnection
Key: WFCORE-1257
URL: https://issues.jboss.org/browse/WFCORE-1257
Project: WildFly Core
Issue Type: Feature Request
Components: JMX
Affects Versions: 2.0.5.Final
Reporter: Chao Wang
There is no implementation for query filter in MBeanServerConnection, marked as TODO
{code:title=ModelControllerMBeanHelper.java|borderStyle=solid}
Set<ObjectName> queryNames(final ObjectName name, final QueryExp query) {
return new RootResourceIterator<Set<ObjectName>>(accessControlUtil, getRootResourceAndRegistration().getResource(),
new ObjectNameMatchResourceAction<Set<ObjectName>>(name) {
Set<ObjectName> set = new HashSet<ObjectName>();
@Override
public boolean onResource(ObjectName resourceName) {
if (name == null || name.apply(resourceName)) {
//TODO check query
set.add(resourceName);
}
return true;
}
@Override
public Set<ObjectName> getResult() {
if (set.size() == 1 && set.contains(ModelControllerMBeanHelper.createRootObjectName(domain))) {
return Collections.emptySet();
}
return set;
}
}).iterate();
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-5918) ServletContext.getResourceAsStream fails in latest CR5 version
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5918?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-5918:
---------------------------------
Assignee: Stuart Douglas (was: Jason Greene)
> ServletContext.getResourceAsStream fails in latest CR5 version
> --------------------------------------------------------------
>
> Key: WFLY-5918
> URL: https://issues.jboss.org/browse/WFLY-5918
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.CR5
> Environment: Wildfly 10.0.0 CR5
> Windows 7
> JDK 1.8_66 64Bit
> Reporter: Alban Chadenas
> Assignee: Stuart Douglas
>
> Struts 1 ActionServlet fails to initialize with latest Wildfly 10.0.0 CR5 though it was working fine on the previous CR4 release. The failure occurs when Servlet tries to read the /WEB-INF/web.xml inside my web application.
> Looking at the struts source code, getServletContext().getResourceAsStream("/WEB-INF/web.xml") returns null during the Servlet initialization.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-5822) Clustering performance regression in ejbremote-dist-sync scenario
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-5822?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-5822 at 12/30/15 2:33 PM:
---------------------------------------------------------------------
Set up some basic byteman scripts to dump out the following information on the server side. The node specified in [BYTEMAN-Get (node)] is the node the invocation is being processed on.
Infinispan processing a get request in DistributionInterceptor. Dumps out command, isOriginLocal. origin, cacheTopologyId, primaryOwner and isKeyLocal:
{noformat}
[BYTEMAN-Get(perf18)] command = GetKeyValueCommand {key=eac549bf-6076-4d09-a6c4-1f9f545e8c6a, flags=null}, isOriginLocal = true, isInTxnScope = true, origin = null, cacheTopologyId = 6, primaryOwner = perf18, isKeyLocal = false
{noformat}
Infinispan processing a put request in DistributionInterceptor. Dumps out command, isOriginLocal. origin, cacheTopologyId, primaryOwner and isKeyLocal:
{noformat}
[BYTEMAN-Put(perf18)] command = PutKeyValueCommand{key=UnknownSessionID [6868556952675068536750685266705766505570704954555069526651494854], value=org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanEntry@1bb137da, flags=[FORCE_SYNCHRONOUS], putIfAbsent=true, valueMatcher=MATCH_EXPECTED, metadata=EmbeddedMetadata{version=null}, successful=true}, isOriginLocal = true, isInTxnScope = true, origin = null, cacheTopologyId = 6, primaryOwner = perf18, isKeyLocal = false
{noformat}
Infinispan needing to do a remote get for a value during DistributionInterceptor processing. Dumps out the key which needs to be accessed remotely:
{noformat}
[BYTEMAN-RetrieveFromRemote(perf18)] key = perf18
{noformat}
This is a first approximation to seeing what is going on here.
The jobs are here:
EAP 6.4.0.GA
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/rachmatowicz___bytem...
EAP 7.0.0.DR4
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/rachmatowicz___bytem...
was (Author: rachmato):
Set up some basic byteman scripts to dump out the following information on the server side. The node specified in [BYTEMAN-Get (node)] is the node the invocation is being processed on.
Infinispan processing a get request in DistributionInterceptor:
{noformat}
[BYTEMAN-Get(perf18)] command = GetKeyValueCommand {key=eac549bf-6076-4d09-a6c4-1f9f545e8c6a, flags=null}, isOriginLocal = true, isInTxnScope = true, origin = null, cacheTopologyId = 6, primaryOwner = perf18, isKeyLocal = false
{noformat}
Infinispan processing a put request in DistributionInterceptor:
{noformat}
[BYTEMAN-Put(perf18)] command = PutKeyValueCommand{key=UnknownSessionID [6868556952675068536750685266705766505570704954555069526651494854], value=org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanEntry@1bb137da, flags=[FORCE_SYNCHRONOUS], putIfAbsent=true, valueMatcher=MATCH_EXPECTED, metadata=EmbeddedMetadata{version=null}, successful=true}, isOriginLocal = true, isInTxnScope = true, origin = null, cacheTopologyId = 6, primaryOwner = perf18, isKeyLocal = false
{noformat}
Infinispan needing to do a remote get for a value during DistributionInterceptor processing:
{noformat}
[BYTEMAN-RetrieveFromRemote(perf18)] key = perf18
{noformat}
This is a first approximation to seeing what is going on here.
The jobs are here:
EAP 6.4.0.GA
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/rachmatowicz___bytem...
EAP 7.0.0.DR4
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/rachmatowicz___bytem...
> Clustering performance regression in ejbremote-dist-sync scenario
> ------------------------------------------------------------------
>
> Key: WFLY-5822
> URL: https://issues.jboss.org/browse/WFLY-5822
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.CR5
> Reporter: Michal Vinkler
> Assignee: Richard Achmatowicz
> Priority: Critical
>
> Compared to EAP 6, all SYNC scenarios have the same/better performance except of this one, wonder why?
> Compare these results:
> stress-ejbremote-dist-sync
> 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...]
> 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...]
> ---------------------------------------
> Just for comparison: ejbremote REPL_SYNC scenario *performs well* on the other hand:
> stress-ejbremote-repl-sync
> 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...]
> 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-5822) Clustering performance regression in ejbremote-dist-sync scenario
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-5822?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-5822 at 12/30/15 2:22 PM:
---------------------------------------------------------------------
Set up some basic byteman scripts to dump out the following information on the server side. The node specified in [BYTEMAN-Get (node)] is the node the invocation is being processed on.
Infinispan processing a get request in DistributionInterceptor:
{noformat}
[BYTEMAN-Get(perf18)] command = GetKeyValueCommand {key=eac549bf-6076-4d09-a6c4-1f9f545e8c6a, flags=null}, isOriginLocal = true, isInTxnScope = true, origin = null, cacheTopologyId = 6, primaryOwner = perf18, isKeyLocal = false
{noformat}
Infinispan processing a put request in DistributionInterceptor:
{noformat}
[BYTEMAN-Put(perf18)] command = PutKeyValueCommand{key=UnknownSessionID [6868556952675068536750685266705766505570704954555069526651494854], value=org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanEntry@1bb137da, flags=[FORCE_SYNCHRONOUS], putIfAbsent=true, valueMatcher=MATCH_EXPECTED, metadata=EmbeddedMetadata{version=null}, successful=true}, isOriginLocal = true, isInTxnScope = true, origin = null, cacheTopologyId = 6, primaryOwner = perf18, isKeyLocal = false
{noformat}
Infinispan needing to do a remote get for a value during DistributionInterceptor processing:
{noformat}
[BYTEMAN-RetrieveFromRemote(perf18)] key = perf18
{noformat}
This is a first approximation to seeing what is going on here.
The jobs are here:
EAP 6.4.0.GA
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/rachmatowicz___bytem...
EAP 7.0.0.DR4
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/rachmatowicz___bytem...
was (Author: rachmato):
Set up some basic byteman scripts to dump out the following information on the server side:
Infinispan processing a get request in DistributionInterceptor:
{noformat}
[BYTEMAN-Get(perf18)] command = GetKeyValueCommand {key=eac549bf-6076-4d09-a6c4-1f9f545e8c6a, flags=null}, isOriginLocal = true, isInTxnScope = true, origin = null, cacheTopologyId = 6, primaryOwner = perf18, isKeyLocal = false
{noformat}
Infinispan processing a put request in DistributionInterceptor:
{noformat}
[BYTEMAN-Put(perf18)] command = PutKeyValueCommand{key=UnknownSessionID [6868556952675068536750685266705766505570704954555069526651494854], value=org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanEntry@1bb137da, flags=[FORCE_SYNCHRONOUS], putIfAbsent=true, valueMatcher=MATCH_EXPECTED, metadata=EmbeddedMetadata{version=null}, successful=true}, isOriginLocal = true, isInTxnScope = true, origin = null, cacheTopologyId = 6, primaryOwner = perf18, isKeyLocal = false
{noformat}
Infinispan needing to do a remote get for a value during DistributionInterceptor processing:
{noformat}
[BYTEMAN-RetrieveFromRemote(perf18)] key = perf18
{noformat}
This is a first approximation to seeing what is going on here.
The jobs are here:
EAP 6.4.0.GA
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/rachmatowicz___bytem...
EAP 7.0.0.DR4
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/rachmatowicz___bytem...
> Clustering performance regression in ejbremote-dist-sync scenario
> ------------------------------------------------------------------
>
> Key: WFLY-5822
> URL: https://issues.jboss.org/browse/WFLY-5822
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.CR5
> Reporter: Michal Vinkler
> Assignee: Richard Achmatowicz
> Priority: Critical
>
> Compared to EAP 6, all SYNC scenarios have the same/better performance except of this one, wonder why?
> Compare these results:
> stress-ejbremote-dist-sync
> 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...]
> 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...]
> ---------------------------------------
> Just for comparison: ejbremote REPL_SYNC scenario *performs well* on the other hand:
> stress-ejbremote-repl-sync
> 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...]
> 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-5822) Clustering performance regression in ejbremote-dist-sync scenario
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-5822?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-5822:
-------------------------------------------
Set up some basic byteman scripts to dump out the following information on the server side:
Infinispan processing a get request in DistributionInterceptor:
{noformat}
[BYTEMAN-Get(perf18)] command = GetKeyValueCommand {key=eac549bf-6076-4d09-a6c4-1f9f545e8c6a, flags=null}, isOriginLocal = true, isInTxnScope = true, origin = null, cacheTopologyId = 6, primaryOwner = perf18, isKeyLocal = false
{noformat}
Infinispan processing a put request in DistributionInterceptor:
{noformat}
[BYTEMAN-Put(perf18)] command = PutKeyValueCommand{key=UnknownSessionID [6868556952675068536750685266705766505570704954555069526651494854], value=org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanEntry@1bb137da, flags=[FORCE_SYNCHRONOUS], putIfAbsent=true, valueMatcher=MATCH_EXPECTED, metadata=EmbeddedMetadata{version=null}, successful=true}, isOriginLocal = true, isInTxnScope = true, origin = null, cacheTopologyId = 6, primaryOwner = perf18, isKeyLocal = false
{noformat}
Infinispan needing to do a remote get for a value during DistributionInterceptor processing:
{noformat}
[BYTEMAN-RetrieveFromRemote(perf18)] key = perf18
{noformat}
This is a first approximation to seeing what is going on here.
The jobs are here:
EAP 6.4.0.GA
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/rachmatowicz___bytem...
EAP 7.0.0.DR4
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/rachmatowicz___bytem...
> Clustering performance regression in ejbremote-dist-sync scenario
> ------------------------------------------------------------------
>
> Key: WFLY-5822
> URL: https://issues.jboss.org/browse/WFLY-5822
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.CR5
> Reporter: Michal Vinkler
> Assignee: Richard Achmatowicz
> Priority: Critical
>
> Compared to EAP 6, all SYNC scenarios have the same/better performance except of this one, wonder why?
> Compare these results:
> stress-ejbremote-dist-sync
> 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...]
> 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...]
> ---------------------------------------
> Just for comparison: ejbremote REPL_SYNC scenario *performs well* on the other hand:
> stress-ejbremote-repl-sync
> 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...]
> 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-5918) ServletContext.getResourceAsStream fails in latest CR5 version
by Alban Chadenas (JIRA)
Alban Chadenas created WFLY-5918:
------------------------------------
Summary: ServletContext.getResourceAsStream fails in latest CR5 version
Key: WFLY-5918
URL: https://issues.jboss.org/browse/WFLY-5918
Project: WildFly
Issue Type: Bug
Affects Versions: 10.0.0.CR5
Environment: Wildfly 10.0.0 CR5
Windows 7
JDK 1.8_66 64Bit
Reporter: Alban Chadenas
Assignee: Jason Greene
Struts 1 ActionServlet fails to initialize with latest Wildfly 10.0.0 CR5 though it was working fine on the previous CR4 release. The failure occurs when Servlet tries to read the /WEB-INF/web.xml inside my web application.
Looking at the struts source code, getServletContext().getResourceAsStream("/WEB-INF/web.xml") returns null during the Servlet initialization.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFCORE-591) revertReloadRequired() throws a NPE is reloadRequired has not been called
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-591?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-591:
------------------------------------------------
Romain Pelisse <rpelisse(a)redhat.com> changed the Status of [bug 1294591|https://bugzilla.redhat.com/show_bug.cgi?id=1294591] from ASSIGNED to VERIFIED
> revertReloadRequired() throws a NPE is reloadRequired has not been called
> -------------------------------------------------------------------------
>
> Key: WFCORE-591
> URL: https://issues.jboss.org/browse/WFCORE-591
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha19
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 1.0.0.Beta1
>
>
> If an operation step handler calls org.jboss.as.controller.OperationContext#revertReloadRequired() when org.jboss.as.controller.OperationContext#reloadRequired() has not been called, it throws a NPE:
> {noformat}
> java.lang.NullPointerException
> at org.jboss.as.controller.ControlledProcessState.revertReloadRequired(ControlledProcessState.java:181)
> at org.jboss.as.controller.AbstractOperationContext.revertReloadRequired(AbstractOperationContext.java:1037)
> at org.jboss.as.controller.test.RevertReloadRequiredTestCase$TestResourceAddHandler.rollbackRuntime(RevertReloadRequiredTestCase.java:98)
> at org.jboss.as.controller.AbstractAddStepHandler$1$1.handleRollback(AbstractAddStepHandler.java:133)
> at org.jboss.as.controller.AbstractOperationContext$RollbackDelegatingResultHandler.handleResult(AbstractOperationContext.java:1419)
> at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1385)
> at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1367)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1323)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1283)
> at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1172)
> at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:929)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:877)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:601)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:354)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:330)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1182)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:362)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:205)
> {noformat}
> The NPE is caused by this.activeStep.restartStamp field which is set only when reloadRequired() (or restartRequired()) is called.
> My OSH may call reloadRequired() or not depending on some runtime state and I could add some logic to make sure I call
> I can fix my handle to check that I call context.revertReloadRequired() only I had previously called reloadRequired () first.
> However, in order to make the OperationContext more robust, I think that the revertReloadRequired() method should instead be a no-op if there is no reload required.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
