[JBoss JIRA] (WFLY-3147) spec-descriptor-property-replacement causes NPE while parsing exclude element in beans.xml
by Maxim Frolov (JIRA)
Maxim Frolov created WFLY-3147:
----------------------------------
Summary: spec-descriptor-property-replacement causes NPE while parsing exclude element in beans.xml
Key: WFLY-3147
URL: https://issues.jboss.org/browse/WFLY-3147
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: CDI / Weld, EE
Affects Versions: 8.0.0.Final
Reporter: Maxim Frolov
Assignee: Stuart Douglas
A CDI Bean Archive with a _beans.xml_ which contains {{beans/scan/*exclude*}} XML element causes {{NullPointerExcpetion}} during deployment on server with enabled {{<spec-descriptor-property-replacement>}} parameter in server's _standalone.xml_.
The error stack trace is:
{noformat}
2014-03-21 11:22:52,455 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-11) MSC000001: Failed to start service jboss.deployment.subunit."example.ear"."example-ejb.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."example.ear"."example-ejb.jar".PARSE: JBAS018733: Failed to process phase PARSE of subdeployment "example-ejb.jar" of deployment "example.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.Final.jar:1.2.0.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException
at org.jboss.as.weld.deployment.processors.BeansXmlProcessor.parseBeansXml(BeansXmlProcessor.java:140)
at org.jboss.as.weld.deployment.processors.BeansXmlProcessor.deploy(BeansXmlProcessor.java:117)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
... 5 more
Caused by: java.lang.NullPointerException
at org.jboss.metadata.property.DefaultPropertyReplacer.replaceProperties(DefaultPropertyReplacer.java:52)
at org.jboss.as.weld.deployment.PropertyReplacingBeansXmlHandler.interpolate(PropertyReplacingBeansXmlHandler.java:64)
at org.jboss.weld.xml.BeansXmlHandler$4.processStartChildElement(BeansXmlHandler.java:229)
at org.jboss.weld.xml.BeansXmlHandler.startElement(BeansXmlHandler.java:297)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaValidator.emptyElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
at org.jboss.weld.xml.BeansXmlParser.parse(BeansXmlParser.java:93)
at org.jboss.as.weld.deployment.processors.BeansXmlProcessor.parseBeansXml(BeansXmlProcessor.java:136)
... 7 more
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-3146) Undertow Memory Leak for JAX-RS requests
by Darren Jones (JIRA)
[ https://issues.jboss.org/browse/WFLY-3146?page=com.atlassian.jira.plugin.... ]
Darren Jones commented on WFLY-3146:
------------------------------------
FWIW - I've just tried a local build with WildFly 8.0.1.Final-SNAPSHOT, locally patched with those POM changes in the pull requests to use XNIO 3.2.1.Final and Undertow 1.0.2.Final.
I am no longer seeing the memory leak.
Many thanks!
> Undertow Memory Leak for JAX-RS requests
> ----------------------------------------
>
> Key: WFLY-3146
> URL: https://issues.jboss.org/browse/WFLY-3146
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Environment: Windows 7 Professional
> JDK 1.7.0_21
> WildFly 8.0.0.Final
> Reporter: Darren Jones
> Assignee: Tomaz Cerar
> Priority: Critical
> Labels: MemoryLeak
> Fix For: 8.0.1.Final
>
> Attachments: hello-client.zip, hello-service-0.1-SNAPSHOT.war, hello-service.zip, JProfiler GC Root.png, server.keystore, standalone.xml, VisualVM Memory.png
>
>
> After half an hour or so of running the automated test suite for our application, the server hangs due to GC and many OutOfMemoryErrors appear in the WildFly server log.
> I've attached VisualVM and JProfiler, both of which demonstrate that many of the objects that are not being garbage collected are Undertow objects. Both tools show that the path to the GC root is via a Java nio SelectionKey, which is held by sun.nio.ch.WindowsSelectorImpl.
> I'll attach a screenshot of a JProfiler window to demonstrate, but VisualVM shows the same result (albeit presented differently).
> I have also found similar behaviour with a small, trivial example, as described in the Steps to Reproduce. It makes repeated calls to a simple RESTful call to a JAX-RS service. The example doesn't cause as fast a leak as our test suite, but it does demonstrate the problem.
> The example uses https for the call because it seems to leak memory faster than http - but http does also exhibit the problem.
> I have also tried patching WildFly 8.0.0.Final up to Undertow.1.0.2-SNAPSHOT and XNIO.3.3.0-SNAPSHOT (as of this morning), but the problem still occurs.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-3141) Change the ModuleMap to map Kerberos to the new JBoss Negotiation KerberosLoginModule
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3141?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-3141.
------------------------------------
Resolution: Done
> Change the ModuleMap to map Kerberos to the new JBoss Negotiation KerberosLoginModule
> -------------------------------------------------------------------------------------
>
> Key: WFLY-3141
> URL: https://issues.jboss.org/browse/WFLY-3141
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 9.0.0.CR1
>
>
> At the moment the ModuleOptions map maps the Kerberos short name to the com.sun LoginModule, instead map to the JBoss Negotation KerberosLoginModule which adds two new capabilities: -
> 1 - Wrap instantiation of whichever module is actually available.
> Note: It does not translate options from one to the other so those are still JDK specific.
> 2 - Adds an addGSSCredential option so that the module will add a GSSCredential to the Subject.
> This part is needed where the returned Subject is then going to be used with JCA.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-3131) isSensitiveValue of class SensitiveVaultExpressionConstraint uses incorrect index in java.lang.String.substring method
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3131?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3131:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1077838|https://bugzilla.redhat.com/show_bug.cgi?id=1077838] from MODIFIED to POST
> isSensitiveValue of class SensitiveVaultExpressionConstraint uses incorrect index in java.lang.String.substring method
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3131
> URL: https://issues.jboss.org/browse/WFLY-3131
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Environment: All
> Reporter: Jay Kumar SenSharma
> Assignee: Jay Kumar SenSharma
>
> The isSensitiveValue(ModelNode value) method of class "org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint" seems to be using the incorrect index in java.lang.String.substring method. Which is causing the following exceptions in the logs while executing the following kind of CLI command:
> {code}
> [standalone@localhost:9990 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=formatter, value="%d{HH:mm:ss,SSS} %-5p [%c] (${jboss.node.name} %t) %s%E%n")
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014749: Operation handler failed: String index out of range: -15",
> "rolled-back" => true
> }
> {code}
> The Exception can be seen as following in the WildFly Logs:
> {code}
> 21:58:04,821 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 25) JBAS014612: Operation ("write-attribute") failed - address: ([
> ("subsystem" => "logging"),
> ("periodic-rotating-file-handler" => "FILE")
> ]): java.lang.StringIndexOutOfBoundsException: String index out of range: -15
> at java.lang.String.substring(String.java:1911) [rt.jar:1.7.0_51]
> at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.isSensitiveValue(SensitiveVaultExpressionConstraint.java:128) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.isSensitiveAction(SensitiveVaultExpressionConstraint.java:89) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.access.constraint.SensitiveVaultExpressionConstraint$Factory.getRequiredConstraint(SensitiveVaultExpressionConstraint.java:81) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.access.rbac.DefaultPermissionFactory.getRequiredPermissions(DefaultPermissionFactory.java:201) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.access.permission.ManagementPermissionAuthorizer.authorize(ManagementPermissionAuthorizer.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer.authorize(DelegatingConfigurableAuthorizer.java:98) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1153) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1055) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1015) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.getResourceRegistration(OperationContextImpl.java:265) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.operations.global.WriteAttributeHandler.execute(WriteAttributeHandler.java:72) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:272) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:146) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:174) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:105) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:125) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:121) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_51]
> at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_51]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:121) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-3112) One can't change history and decay with DynamicLoadBalanceFactorProvider
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3112?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3112:
-----------------------------------------------
Michal Babacek <mbabacek(a)redhat.com> changed the Status of [bug 1075215|https://bugzilla.redhat.com/show_bug.cgi?id=1075215] from ON_QA to VERIFIED
> One can't change history and decay with DynamicLoadBalanceFactorProvider
> ------------------------------------------------------------------------
>
> Key: WFLY-3112
> URL: https://issues.jboss.org/browse/WFLY-3112
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Michal Babacek
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 8.0.1.Final
>
> Attachments: redacted_log
>
>
> I'm under an ugly impression that one can't actually change {{history}} and {{decay}} attributes of *DynamicLoadBalanceFactorProvider*.
> I was trying to figure out why the new test suite of CustomLoadMetric tests does not pass. In order to get load figures without history and decay manipulation, I set the following:
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
> <mod-cluster-config advertise-socket="modcluster" connector="ajp">
> <dynamic-load-provider history="0">
> <custom-load-metric class="biz.karms.modcluster.CustomLoadMetric" weight="1">
> <property name="capacity" value="1000"/>
> <property name="loadfile" value="/tmp/mod_cluster-eapx/loadfileA"/>
> <property name="parseexpression" value="^LOAD: ([0-9]*)$"/>
> </custom-load-metric>
> </dynamic-load-provider>
> </mod-cluster-config>
> </subsystem>
> {code}
> The aforementioned {{history=0}} effectively means that there is just 1 "slot" for a one historical value on which decay function should work.
> If you take a look at the code in [DynamicLoadBalanceFactorProvider|https://github.com/modcluster/mod_cluste...] constructor, it is apparent
> that the size of the List that later serves for storing the historical values is set sooner than the actual [setHistory(int history)|https://github.com/modcluster/mod_cluster/blob/master/core/src/m...] method is called.
> The actual size of that List collection wouldn't do any harm by itself but it is being used in the aforementioned class with {{.size()}} to control cycles.
> The same IMHO holds for the decay attribute.
> Anyhow, I put some additional logging to the [DynamicLoadBalanceFactorProvider.java|https://github.com/modcluster/mod_c...]:
> {code}
> // Historical value contribute an exponentially decayed factor
> for (int i = 0; i < queue.size(); ++i) {
> double decay = 1 / Math.pow(decayFactor, i);
> totalDecay += decay;
> this.log.info("KTAG: totalLoad:"+totalLoad+", with decay:"+(totalLoad+queue.get(i).doubleValue() * decay));
> totalLoad += queue.get(i).doubleValue() * decay;
> }
> {code}
> and
> {code}
> try {
> // Normalize load with respect to capacity
> this.recordLoad(metricLoadHistory, metric.getLoad(engine) / metric.getCapacity());
> this.log.info("KTAG metricLoadHistory:"+metricLoadHistory.toString());
> totalWeight += weight;
> totalWeightedLoad += this.average(metricLoadHistory) * weight;
> } catch (Exception e) {
> this.log.error(e.getLocalizedMessage(), e);
> }
> {code}
> with the following being the output: [^redacted_log].
> So, despite having {{history=0}}, which should force the system to keep just 1, the current value, {{metricLoadHistory}} grew from
> {noformat}
> KTAG metricLoadHistory:[0.8]
> {noformat}
> to
> {noformat}
> KTAG metricLoadHistory:[0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.8]
> {noformat}
> which is exactly [9|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/jav...] + [1|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/jav...] in size :-)
> WDYT?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months
[JBoss JIRA] (WFLY-3144) Session replication doesn't work as expected
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/WFLY-3144?page=com.atlassian.jira.plugin.... ]
Tomas Remes commented on WFLY-3144:
-----------------------------------
Reproducible also by TranslatorClusterTest from https://github.com/maschmid/weld-clustering-tests. Replace PATH* variables with your values and you can use following command:
{noformat}
mvn clean verify -Darquillian=wildfly-cluster-8 -Dnode1.jbossHome=${PATH1} -Dnode2.jbossHome=${PATH2} -Dnode1.contextPath="http://127.0.0.1:8080/weld-clustering-tests" -Dnode2.contextPath="http://127.0.0.1:8180/weld-clustering-tests" -Dnode1.managementAddress=127.0.0.1 -Dnode1.managementPort=9990 -Dnode2.managementAddress=127.0.0.1 -Dnode2.managementPort=10090 -Dnode2.portOffset=100 -Dtest=TranslatorClusterTest
{noformat}
> Session replication doesn't work as expected
> --------------------------------------------
>
> Key: WFLY-3144
> URL: https://issues.jboss.org/browse/WFLY-3144
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, EJB
> Affects Versions: 8.0.0.Final
> Reporter: Tomas Remes
> Assignee: Stuart Douglas
> Attachments: translator.zip
>
>
> I am experimenting with quite simple Stateful SessionScoped bean ( see org.jboss.weld.tests.clustering.translator.TranslatorControllerBean from attached reproducer) and actually there's not any specific exception, but the behavior is at least weird. I haven't tried with plain EJB so far. Reproducible by following steps:
> 1. Run first node with "/bin/standalone.sh -c standalone-ha.xml"
> 2. Run second node with "./bin/standalone.sh -c standalone-ha.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=second"
> 3. Build and deploy attached reproducer
> 4. Open 127.0.0.1:8080/translator in your browser and translate something.
> 5. Open 127.0.0.1:8180/translator and note that number of translated sentences is not replicated correctly.
> This works correctly in EAP. I am running with default standalone-ha configuration on oracle's 1.7.0_45 jdk.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 9 months