December 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1210) Transformations are not triggered for aliases

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1210?page=com.atlassian.jira.plugi... ] Radoslav Husar reassigned WFCORE-1210: -------------------------------------- Assignee: Kabir Khan (was: Brian Stansberry) > Transformations are not triggered for aliases > --------------------------------------------- > > Key: WFCORE-1210 > URL: https://issues.jboss.org/browse/WFCORE-1210 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.4.Final > Reporter: Radoslav Husar > Assignee: Kabir Khan > Priority: Critical > Fix For: 2.0.5.Final > > > [14:19] Kabir Khan: perhaps the transformer framework should be smart enough to map the alias to the real address and then transform that -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[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: ------------------------------------------- Michal, that's great. I just had a quick look at BaseDistributionInterceptor and there is trace level logging which gives more or less the same information that we need (maybe a little more than desired though). So, in the first instance, could you please re-run the job with TRACE logging on this class: org.infinispan.interceptors.distribution.BaseDistributionInterceptor This class handles remote gets and logs information about which gets were remote and which were not. It is likely that we can see the problem from this information without having to write a custom Byteman script. > 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 > > 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)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1005) Upgrade to joda time 2.1

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-1005?page=com.atlassian.jira.plugin.... ] Brian Stansberry resolved WFLY-1005. ------------------------------------ Resolution: Out of Date > Upgrade to joda time 2.1 > ------------------------ > > Key: WFLY-1005 > URL: https://issues.jboss.org/browse/WFLY-1005 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System > Environment: - > Reporter: Wouter Oet > > JBoss AS 7.1.1 ships with Joda-time 1.6.2, however the newer version 2.1 is available and contains bugfixes and improvements. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5839) Create "Best practice" document for writing tests

by Rostislav Svoboda (JIRA)

Rostislav Svoboda created WFLY-5839: --------------------------------------- Summary: Create "Best practice" document for writing tests Key: WFLY-5839 URL: https://issues.jboss.org/browse/WFLY-5839 Project: WildFly Issue Type: Task Components: Test Suite Reporter: Rostislav Svoboda Assignee: Tomaz Cerar Please create "Best practice" document for writing tests In AS TS there are currently multiple solutions for the same thing, ARQ is used where WF deployer would be sufficient, tests are not exactly in the correct location - they can be even in WF Core TS. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5838) Use WildFly thread pools in Artemis

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-5838: --------------------------------- Summary: Use WildFly thread pools in Artemis Key: WFLY-5838 URL: https://issues.jboss.org/browse/WFLY-5838 Project: WildFly Issue Type: Enhancement Components: JMS Affects Versions: 10.0.0.CR4 Reporter: Jeff Mesnil Assignee: Jeff Mesnil Artemis provides a feature to inject its executor and scheduled executor services when a ArtemisServer is created. WildFly could leverage that to inject these services so that their thread pools are managed by WildFly. We would have total control on the creation and configuration of these thread pools using the org.boss.as.threads extension. The messaging-activemq extension would be updated so that a server resource would have new children using resource definitions from the org.boss.as.threads extension to configure their pools. {noformat} * server * bounded-queue-thread-pool or unbounded-queue-thread-pool -> for executor service * scheduled-thread-pool -> for scheduled executor service {noformat} Note that this RFE would not impact the Artemis RA that does not provide such executor injection. This will be covered by another JIRA issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-785) no MVEL debugger registered to handle breakpoint

by Maurice Betzel (JIRA)

[ https://issues.jboss.org/browse/DROOLS-785?page=com.atlassian.jira.plugin... ] Maurice Betzel updated DROOLS-785: ---------------------------------- Steps to Reproduce: Add dialect "mvel" to rule file and Right click HelloWorldApplication to debug as Drools application (was: Right click HelloWorldApplication and debug as Drools application) Affects Version/s: 6.3.0.Final > no MVEL debugger registered to handle breakpoint > ------------------------------------------------ > > Key: DROOLS-785 > URL: https://issues.jboss.org/browse/DROOLS-785 > Project: Drools > Issue Type: Bug > Components: core engine, eclipse plugin > Affects Versions: 6.2.0.Final, 6.3.0.Final > Environment: Win 7 64, JBoss Developer Studio Version: 8.1.0.GA, JBossAS Tools 3.0.3.Final-v20150325-0035-B129, Java 1.7.0_76 > Reporter: Maurice Betzel > Assignee: Petr Široký > Priority: Blocker > > Executing Drools-Examples 6.0.2.Final from github containing MVEL dialect resulted in runtime exception: > 2015-05-16 14:35:28,603 [main] INFO Found kmodule: file:/C:/Users/x3.mbetzel/Development/workspaces/jboss-drools/drools-examples-62/target/classes/META-INF/kmodule.xml > 2015-05-16 14:35:28,999 [main] INFO KieModule was added: FileKieModule[releaseId=org.drools:drools-examples:6.2.0.Final,file=C:\Users\x3.mbetzel\Development\workspaces\jboss-drools\drools-examples-62\target\classes] > Exception in thread "main" java.lang.RuntimeException: no debugger registered to handle breakpoint > at org.mvel2.debug.DebuggerContext.checkBreak(DebuggerContext.java:98) > at org.mvel2.MVELRuntime.execute(MVELRuntime.java:76) > at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123) > at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119) > at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:113) > at org.mvel2.MVEL.executeExpression(MVEL.java:930) > at org.drools.core.util.MVELSafeHelper$RawMVELEvaluator.executeExpression(MVELSafeHelper.java:481) > at org.drools.core.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:77) > at org.drools.core.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:62) > at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:230) > at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:187) > at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:141) > at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:504) > at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:379) > at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:290) > at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:253) > at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:370) > at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:289) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1480) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1422) > at org.drools.examples.helloworld.HelloWorldExample.main(HelloWorldExample.java:65) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1989) Bundlers: reuse send buffer when transport == sync.

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1989?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1989: -------------------------------- You don't give up, do you? :-) Even the most light-weight impl adds ~16 bytes to every message [1], and I'm not willing to add that cost. Looking at my previous comment, that may not even be necessary, because it seems we can reuse buffers *for sure* for 75% of our use cases: * Sending of message batches: OK * Sending of single messages: OK * Reception of message batches: OK * Reception of single messages: MAYBE The last 25% (reception of single messages) is (1) not a big use case as most messages are received as batches anyway and (2) we could come up with requirements for how the {{receive()}} callback needs to use the buffer in the message argument. For instance, we could say that a buffer needs to be read and data in it needs to be de-serialized before {{receive()}} returns, or a copy has to be made. I also need to look at how retransmission is affected in {{NAKACK2}} and {{UNICAST3}}. Actually, most callbacks do perform de-serialization right away, with some exceptions (e.g. Async Invocation API), so they should be conformant. [1] https://github.com/belaban/workshop/blob/master/slides/status2015.adoc#si... > Bundlers: reuse send buffer when transport == sync. > --------------------------------------------------- > > Key: JGRP-1989 > URL: https://issues.jboss.org/browse/JGRP-1989 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.7 > > > With the addition of {{TCP_NIO2}}, all bundlers now create new send buffers for every message (or message list). This generates a lot of memory allocations, perhaps it is better to revert this change for *synchronous transports* such as {{UDP}} and {{TCP}}, and still create new buffers for *asynchronous transports* such as {{TCP_NIO2}}. > Synchronous transports guarantee a message has been put on the wire when {{TP.send()}} returns, whereas asynchronous transports may only have completed a partial write (so we cannot reuse the buffer). > The code in the bundler should check for this, and copy if async or not copy if sync. > Whether or not a transport is sync is determined by a new abstract method that needs to be overridden by every transport. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5836) Stale session data received when using REPL SYNC on jvmkill

by Michal Vinkler (JIRA)

Michal Vinkler created WFLY-5836: ------------------------------------ Summary: Stale session data received when using REPL SYNC on jvmkill Key: WFLY-5836 URL: https://issues.jboss.org/browse/WFLY-5836 Project: WildFly Issue Type: Bug Components: Clustering Reporter: Michal Vinkler Assignee: Paul Ferraro Priority: Minor Client received older data when using REPL SYNC right after failing perf21 (jvmkill). -- seen only once, hardly reproducible Timeline & stacktrace: {code} 2015/11/27 15:05:40:255 EST [INFO ][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Failing node 3 (perf21) 2015/11/27 15:05:40:459 EST [INFO ][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Node 3 (perf21) is down. 2015/11/27 15:05:40:459 EST [INFO ][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Cluster state: [UP, UP, UP, DOWN]. 2015/11/27 15:05:45:758 EST [INFO ][Runner - 725] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Failover detected, JvmRoute changed. perf21 -> perf20 2015/11/27 15:05:45:774 EST [INFO ][Runner - 1962] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Failover detected, JvmRoute changed. perf21 -> perf19 : : 2015/11/27 15:05:49:999 EST [INFO ][Runner - 522] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Failover detected, JvmRoute changed. perf21 -> perf20 2015/11/27 15:05:50:533 EST [INFO ][Runner - 314] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Failover detected, JvmRoute changed. perf21 -> perf20 2015/11/27 15:05:53:908 EST [WARN ][Runner - 14] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 139, received 138, Runner: 14> org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 139, received 138, Runner: 14 at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:133) at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52) at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103) at java.lang.Thread.run(Thread.java:745) {code} Link http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-http-... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5836) Stale session data received when using REPL SYNC on jvmkill

by Michal Vinkler (JIRA)

[ https://issues.jboss.org/browse/WFLY-5836?page=com.atlassian.jira.plugin.... ] Michal Vinkler updated WFLY-5836: --------------------------------- Affects Version/s: 10.0.0.CR4 > Stale session data received when using REPL SYNC on jvmkill > ----------------------------------------------------------- > > Key: WFLY-5836 > URL: https://issues.jboss.org/browse/WFLY-5836 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR4 > Reporter: Michal Vinkler > Assignee: Paul Ferraro > Priority: Minor > > Client received older data when using REPL SYNC right after failing perf21 (jvmkill). > -- seen only once, hardly reproducible > Timeline & stacktrace: > {code} > 2015/11/27 15:05:40:255 EST [INFO ][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Failing node 3 (perf21) > 2015/11/27 15:05:40:459 EST [INFO ][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Node 3 (perf21) is down. > 2015/11/27 15:05:40:459 EST [INFO ][TestController] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Cluster state: [UP, UP, UP, DOWN]. > 2015/11/27 15:05:45:758 EST [INFO ][Runner - 725] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Failover detected, JvmRoute changed. perf21 -> perf20 > 2015/11/27 15:05:45:774 EST [INFO ][Runner - 1962] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Failover detected, JvmRoute changed. perf21 -> perf19 > : > : > 2015/11/27 15:05:49:999 EST [INFO ][Runner - 522] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Failover detected, JvmRoute changed. perf21 -> perf20 > 2015/11/27 15:05:50:533 EST [INFO ][Runner - 314] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Failover detected, JvmRoute changed. perf21 -> perf20 > 2015/11/27 15:05:53:908 EST [WARN ][Runner - 14] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 139, received 138, Runner: 14> > org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 139, received 138, Runner: 14 > at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:133) > at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52) > at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103) > at java.lang.Thread.run(Thread.java:745) > {code} > Link > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-http-... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5837) Upgrade RESTEasy to 3.0.14.Final

by Weinan Li (JIRA)

Weinan Li created WFLY-5837: ------------------------------- Summary: Upgrade RESTEasy to 3.0.14.Final Key: WFLY-5837 URL: https://issues.jboss.org/browse/WFLY-5837 Project: WildFly Issue Type: Component Upgrade Components: REST Reporter: Weinan Li Assignee: Weinan Li Fix For: 10.0.0.CR5 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2015