[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)
9 years, 11 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)
9 years, 11 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)
9 years, 11 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 NEW 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)
9 years, 11 months
[JBoss JIRA] (WFLY-5652) Datasource spy attribute has no effect
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/WFLY-5652?page=com.atlassian.jira.plugin.... ]
Jesper Pedersen reassigned WFLY-5652:
-------------------------------------
Assignee: Lin Gao (was: Jesper Pedersen)
> Datasource spy attribute has no effect
> --------------------------------------
>
> Key: WFLY-5652
> URL: https://issues.jboss.org/browse/WFLY-5652
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.0.0.CR2
> Reporter: Rich DiCroce
> Assignee: Lin Gao
>
> The spy attribute of a datasource does not appear to have any effect. The datasources XSD says to set spy to true and enable the org.jboss.jdbc log category, but I did that and got no debug info in my log. From a quick search of the WildFly and IronJacamar codebases, it looks like no meaningful code ever checks the value of the spy attribute.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-5917) numberOfLogicalViews not working
by Gabriel Vieira (JIRA)
[ https://issues.jboss.org/browse/WFLY-5917?page=com.atlassian.jira.plugin.... ]
Gabriel Vieira updated WFLY-5917:
---------------------------------
Description:
Theres a bug in wildfly 9 Final
Even if a set on web.xml
{code:java}
<context-param>
<param-name>com.sun.faces.numberOfLogicalViews</param-name>
<param-value>3</param-value>
</context-param>
{code}
It keep storing 25 views.
I tried @Named (CDI) and @ManagedBean and the problem persisted.
My workaround was use @ViewScoped from Omnifaces
was:
Theres a bug in wildfly 9 Final
Even if a set on web.xml
{code:java}
<context-param>
<param-name>com.sun.faces.numberOfLogicalViews</param-name>
<param-value>3</param-value>
</context-param>
{code}
it keep storing 25 views.
I tried @Named (CDI) and @ManagedBean and the problem persisted.
My workaround was use @ViewScoped from Omnifaces
> numberOfLogicalViews not working
> --------------------------------
>
> Key: WFLY-5917
> URL: https://issues.jboss.org/browse/WFLY-5917
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JSF
> Affects Versions: 9.0.2.Final
> Reporter: Gabriel Vieira
> Assignee: Stuart Douglas
> Labels: cdi, jsf22, wildfly
>
> Theres a bug in wildfly 9 Final
> Even if a set on web.xml
> {code:java}
> <context-param>
> <param-name>com.sun.faces.numberOfLogicalViews</param-name>
> <param-value>3</param-value>
> </context-param>
> {code}
> It keep storing 25 views.
> I tried @Named (CDI) and @ManagedBean and the problem persisted.
> My workaround was use @ViewScoped from Omnifaces
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-5917) numberOfLogicalViews not working
by Gabriel Vieira (JIRA)
[ https://issues.jboss.org/browse/WFLY-5917?page=com.atlassian.jira.plugin.... ]
Gabriel Vieira updated WFLY-5917:
---------------------------------
Description:
Theres a bug in wildfly 9 Final
Even if a set on web.xml
{code:java}
<context-param>
<param-name>com.sun.faces.numberOfLogicalViews</param-name>
<param-value>3</param-value>
</context-param>
{code}
it keep storing 25 views.
I tried @Named (CDI) and @ManagedBean and the problem persisted.
My workaround was use @ViewScoped from Omnifaces
was:
Theres a bug in wildfly 9 Final
Even if a set on web.xml
{code:java}
<context-param>
<param-name>com.sun.faces.numberOfLogicalViews</param-name>
<param-value>3</param-value>
</context-param>
{code}
it keeps storing 25 views.
I tried @Named (CDI) and @ManagedBean and the problem persisted.
My workaround was use @ViewScoped from Omnifaces
> numberOfLogicalViews not working
> --------------------------------
>
> Key: WFLY-5917
> URL: https://issues.jboss.org/browse/WFLY-5917
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JSF
> Affects Versions: 9.0.2.Final
> Reporter: Gabriel Vieira
> Assignee: Stuart Douglas
> Labels: cdi, jsf22, wildfly
>
> Theres a bug in wildfly 9 Final
> Even if a set on web.xml
> {code:java}
> <context-param>
> <param-name>com.sun.faces.numberOfLogicalViews</param-name>
> <param-value>3</param-value>
> </context-param>
> {code}
> it keep storing 25 views.
> I tried @Named (CDI) and @ManagedBean and the problem persisted.
> My workaround was use @ViewScoped from Omnifaces
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-5917) numberOfLogicalViews not working
by Gabriel Vieira (JIRA)
[ https://issues.jboss.org/browse/WFLY-5917?page=com.atlassian.jira.plugin.... ]
Gabriel Vieira updated WFLY-5917:
---------------------------------
Steps to Reproduce:
1-Create a WEB project
2-Create a @ViewScoped and log @PostConstruct and @PreDestroy.
3-Set com.sun.faces.numberOfLogicalViews to 3 (or any other number) on web.xml.
4-Create a page that call the View created (Step 2).
5-You will notice that it will store view ultil max 25 (LRU map).
was:
1-Create a WEB project
2-Create a @ViewScoped and log @PostConstruct and @PreDestroy.
3-Set com.sun.faces.numberOfLogicalViews to 3 (or any other number).
4-Create a page that call the View created (Step 2).
5-You will notice that it will store view ultil max 25 (LRU map).
> numberOfLogicalViews not working
> --------------------------------
>
> Key: WFLY-5917
> URL: https://issues.jboss.org/browse/WFLY-5917
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JSF
> Affects Versions: 9.0.2.Final
> Reporter: Gabriel Vieira
> Assignee: Stuart Douglas
> Labels: cdi, jsf22, wildfly
>
> Theres a bug in wildfly 9 Final
> Even if a set on web.xml
> {code:java}
> <context-param>
> <param-name>com.sun.faces.numberOfLogicalViews</param-name>
> <param-value>3</param-value>
> </context-param>
> {code}
> it keeps storing 25 views.
> I tried @Named (CDI) and @ManagedBean and the problem persisted.
> My workaround was use @ViewScoped from Omnifaces
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-5917) numberOfLogicalViews not working
by Gabriel Vieira (JIRA)
[ https://issues.jboss.org/browse/WFLY-5917?page=com.atlassian.jira.plugin.... ]
Gabriel Vieira updated WFLY-5917:
---------------------------------
Steps to Reproduce:
1-Create a WEB project
2-Create a @ViewScoped and log @PostConstruct and @PreDestroy.
3-Set com.sun.faces.numberOfLogicalViews to 3 (or any other number).
4-Create a page that call the View created (Step 2).
5-You will notice that it will store view ultil max 25 (LRU map).
was:
1-Create a WEB project
2-Create a @ViewScoped and log @PostConstruct and @PreDestroy to log it.
3-Set com.sun.faces.numberOfLogicalViews to 3 (or any other number).
4-Create a page that call the View created (Step 2).
5-You will notice that it will store view ultil max 25 (LRU map).
> numberOfLogicalViews not working
> --------------------------------
>
> Key: WFLY-5917
> URL: https://issues.jboss.org/browse/WFLY-5917
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JSF
> Affects Versions: 9.0.2.Final
> Reporter: Gabriel Vieira
> Assignee: Stuart Douglas
> Labels: cdi, jsf22, wildfly
>
> Theres a bug in wildfly 9 Final
> Even if a set on web.xml
> {code:java}
> <context-param>
> <param-name>com.sun.faces.numberOfLogicalViews</param-name>
> <param-value>3</param-value>
> </context-param>
> {code}
> it keeps storing 25 views.
> I tried @Named (CDI) and @ManagedBean and the problem persisted.
> My workaround was use @ViewScoped from Omnifaces
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-5917) numberOfLogicalViews not working
by Gabriel Vieira (JIRA)
Gabriel Vieira created WFLY-5917:
------------------------------------
Summary: numberOfLogicalViews not working
Key: WFLY-5917
URL: https://issues.jboss.org/browse/WFLY-5917
Project: WildFly
Issue Type: Bug
Components: CDI / Weld, JSF
Affects Versions: 9.0.2.Final
Reporter: Gabriel Vieira
Assignee: Stuart Douglas
Theres a bug in wildfly 9 Final
Even if a set on web.xml
{code:java}
<context-param>
<param-name>com.sun.faces.numberOfLogicalViews</param-name>
<param-value>3</param-value>
</context-param>
{code}
it keeps storing 25 views.
I tried @Named (CDI) and @ManagedBean and the problem persisted.
My workaround was use @ViewScoped from Omnifaces
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
