[JBoss JIRA] (DROOLS-604) Problems in code generation and parsing when a method is called from Guided Rules Editor
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-604?page=com.atlassian.jira.plugin... ]
Jozef Marko updated DROOLS-604:
-------------------------------
Labels: drools-tools (was: )
> Problems in code generation and parsing when a method is called from Guided Rules Editor
> ----------------------------------------------------------------------------------------
>
> Key: DROOLS-604
> URL: https://issues.jboss.org/browse/DROOLS-604
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.Beta1, 6.2.0.Beta2, 6.2.0.Beta3
> Reporter: Abel Marrero Santos
> Assignee: Michael Anstis
> Priority: Critical
> Labels: drools-tools
> Attachments: model-base-0.0.1-SNAPSHOT.jar
>
>
> I have found a problem in code generation when we use the feature "call a method on <variable>" from the Guided Rule Editor. An InvocationTargetException caused by a ClassCastException is thrown in RuleModelDRLPersistenceImpl.generateSetMethodCallsMethod method.
> I have found other issues that I think are related and that I will try to mention in the comments. I can also provide you with the maven artifact that I'm using.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-604) Problems in code generation and parsing when a method is called from Guided Rules Editor
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-604?page=com.atlassian.jira.plugin... ]
Jozef Marko updated DROOLS-604:
-------------------------------
Component/s: Guided Rule Editor
> Problems in code generation and parsing when a method is called from Guided Rules Editor
> ----------------------------------------------------------------------------------------
>
> Key: DROOLS-604
> URL: https://issues.jboss.org/browse/DROOLS-604
> Project: Drools
> Issue Type: Bug
> Components: Guided Rule Editor
> Affects Versions: 6.1.0.Final, 6.2.0.Beta1, 6.2.0.Beta2, 6.2.0.Beta3
> Reporter: Abel Marrero Santos
> Assignee: Michael Anstis
> Priority: Critical
> Labels: drools-tools
> Attachments: model-base-0.0.1-SNAPSHOT.jar
>
>
> I have found a problem in code generation when we use the feature "call a method on <variable>" from the Guided Rule Editor. An InvocationTargetException caused by a ClassCastException is thrown in RuleModelDRLPersistenceImpl.generateSetMethodCallsMethod method.
> I have found other issues that I think are related and that I will try to mention in the comments. I can also provide you with the maven artifact that I'm using.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2734) [Guided Decision Table] - Zooming
by Roger Martínez (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2734?page=com.atlassian.jira.plugi... ]
Roger Martínez edited comment on DROOLS-2734 at 7/16/18 3:07 PM:
-----------------------------------------------------------------
Hey [~mstevens1]
Lemme please double check with [~manstis], but I guess zooming for GDT and for any Stunner based editor (BPMN, CM; DMN) are two separate things, although we can apply same interface and capabilities, they're completely different implementations.
We have actually another ticket for Stunner, so looks good for me having 2 tickets for this, just throwing this comment to be all on same page... :)
Thanks guys!
was (Author: roger600):
Hey [~mstevens1]
Lemme please double check with [~manstis], but I guess zooming for GDT and for any Stunner based editor (BPMN, CM; DMN) are two separate things, although we can apply same interface and capabilities, they're completely different implementations.
Thanks guys!
> [Guided Decision Table] - Zooming
> ---------------------------------
>
> Key: DROOLS-2734
> URL: https://issues.jboss.org/browse/DROOLS-2734
> Project: Drools
> Issue Type: Story
> Components: Guided Decision Table Editor
> Reporter: Matthew Stevens
> Assignee: Michael Anstis
> Labels: UX, UXTeam
>
> In order to improve zoom capabilities, a first priority is to better align current capabilities across the workbench, specifically GDT and Stunner.
> *For GDT*
> # Add support for Control click with mouse wheel or trackpad to zoom like Stunner.
> # Add keyboard support for Control click with +/- to allow users to cycle through the different zoom levels.
> A long term solution might move these controls to the canvas, add more zoom levels, and add a slider. But aligning things is a good start.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2734) [Guided Decision Table] - Zooming
by Roger Martínez (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2734?page=com.atlassian.jira.plugi... ]
Roger Martínez commented on DROOLS-2734:
----------------------------------------
Hey [~mstevens1]
Lemme please double check with [~manstis], but I guess zooming for GDT and for any Stunner based editor (BPMN, CM; DMN) are two separate things, although we can apply same interface and capabilities, they're completely different implementations.
Thanks guys!
> [Guided Decision Table] - Zooming
> ---------------------------------
>
> Key: DROOLS-2734
> URL: https://issues.jboss.org/browse/DROOLS-2734
> Project: Drools
> Issue Type: Story
> Components: Guided Decision Table Editor
> Reporter: Matthew Stevens
> Assignee: Michael Anstis
> Labels: UX, UXTeam
>
> In order to improve zoom capabilities, a first priority is to better align current capabilities across the workbench, specifically GDT and Stunner.
> *For GDT*
> # Add support for Control click with mouse wheel or trackpad to zoom like Stunner.
> # Add keyboard support for Control click with +/- to allow users to cycle through the different zoom levels.
> A long term solution might move these controls to the canvas, add more zoom levels, and add a slider. But aligning things is a good start.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10700) WildFly13 Infinispan Query
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10700?page=com.atlassian.jira.plugin... ]
Paul Ferraro closed WFLY-10700.
-------------------------------
Resolution: Rejected
To use infinispan-query with a server-managed cache, you need to create a server module and add it as a dependency of the org.infinispan module.
Alternatively, you can configure the cache-container you intend to use with module="org.infinispan.query", assuming that matches the name of your module containing infinispan-query.
> WildFly13 Infinispan Query
> ---------------------------
>
> Key: WFLY-10700
> URL: https://issues.jboss.org/browse/WFLY-10700
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Environment: {color:#14892c}Pom.xml{color}
> {code}
> <!-- cache -->
> <infinispan.version>9.2.4.Final</infinispan.version>
> <dependency>
> <groupId>org.infinispan</groupId>
> <artifactId>infinispan-core</artifactId>
> <version>${infinispan.version}</version>
> </dependency>
> <dependency>
> <groupId>org.infinispan</groupId>
> <artifactId>infinispan-commons</artifactId>
> <version>${infinispan.version}</version>
> </dependency>
> <dependency>
> <groupId>org.infinispan</groupId>
> <artifactId>infinispan-cachestore-jdbc</artifactId>
> <version>${infinispan.version}</version>
> </dependency>
> <dependency>
> <groupId>org.infinispan</groupId>
> <artifactId>infinispan-cachestore-jpa</artifactId>
> <version>${infinispan.version}</version>
> </dependency>
> <dependency>
> <groupId>org.infinispan</groupId>
> <artifactId>infinispan-query</artifactId>
> <version>${infinispan.version}</version>
> </dependency>
> <dependency>
> <groupId>org.infinispan</groupId>
> <artifactId>infinispan-query-dsl</artifactId>
> <version>${infinispan.version}</version>
> </dependency>
> <dependency>
> <groupId>org.infinispan</groupId>
> <artifactId>infinispan-client-hotrod</artifactId>
> <version>${infinispan.version}</version>
> <scope>compile</scope>
> </dependency>
> <dependency>
> <groupId>org.infinispan</groupId>
> <artifactId>infinispan-lucene-directory</artifactId>
> <version>${infinispan.version}</version>
> </dependency>
> <dependency>
> <groupId>org.infinispan</groupId>
> <artifactId>infinispan-objectfilter</artifactId>
> <version>${infinispan.version}</version>
> </dependency>
> <dependency>
> <groupId>org.infinispan</groupId>
> <artifactId>infinispan-directory-provider</artifactId>
> <version>${infinispan.version}</version>
> </dependency>
> <dependency>
> <groupId>org.infinispan.protostream</groupId>
> <artifactId>protostream</artifactId>
> <version>4.0.0.Final</version>
> </dependency>
> {code}
> -----------------------------------------------------------------------------------------------
> {color:#14892c}jboss-deployment-structure.xml{color}
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <deployment>
> <dependencies>
> <!--
> we want to use the saaj module provided by JBoss
> it looks like we can't use the implementation provided by the JDK - JBoss somehow does not seem to allow it
> -->
> <module name="com.sun.xml.messaging.saaj" />
> <module name="org.antlr" export="true" services="export" />
> <module name="org.infinispan" export="true" />
> <module name="org.infinispan.commons" export="true" />
> <module name="org.hibernate.search.engine" export="true"/>
> </dependencies>
> </deployment>
> </jboss-deployment-structure>
> {code}
> ------------------------------------------------------------
> {code}
> {color:#f79232}CacheContainer{color} container = (CacheContainer) {color:#f79232}new{color}
> javax.naming.InitialContext().lookup(Configuration.getProperty("cache_name").trim());
> this.{color:#205081}cache{color} =container.getCache();
> {code}
> -----------------------------------------------------------------------
> {code}
> {color:#59afe1}QueryFactory{color} queryFactory = {color:#59afe1}org.infinispan.query.Search.getQueryFactory{color}({color:#205081}systemManager.getCache(){color});
> {code}
> Reporter: Majid Mostafavi
> Assignee: Paul Ferraro
>
> {color:#d04437}16:58:45,501 ERROR [stderr] (default task-5) org.infinispan.commons.CacheException: ISPN014038: infinispan-query.jar module is in the classpath but has not been properly initialised!
> 16:58:45,502 ERROR [stderr] (default task-5) at org.infinispan.query.Search.getQueryFactory(Search.java:60)
> 16:58:45,502 ERROR [stderr] (default task-5) at ir.ac.tums.core.utils.SystemManager$Proxy$_$$_WeldClientProxy.findOrganizations(Unknown Source)
> 16:58:45,502 ERROR [stderr] (default task-5) at ir.ac.tums.core.managedBean.SystemManagerBean.findOrganizations(SystemManagerBean.java:48)
> 16:58:45,503 ERROR [stderr] (default task-5) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 16:58:45,503 ERROR [stderr] (default task-5) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 16:58:45,503 ERROR [stderr] (default task-5) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 16:58:45,503 ERROR [stderr] (default task-5) at java.lang.reflect.Method.invoke(Method.java:498)
> 16:58:45,503 ERROR [stderr] (default task-5) at com.sun.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:181)
> 16:58:45,503 ERROR [stderr] (default task-5) at com.sun.el.parser.AstValue.invoke(AstValue.java:289)
> 16:58:45,503 ERROR [stderr] (default task-5) at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304)
> 16:58:45,504 ERROR [stderr] (default task-5) at org.jboss.weld.module.web.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40)
> 16:58:45,504 ERROR [stderr] (default task-5) at org.jboss.weld.module.web.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50)
> 16:58:45,504 ERROR [stderr] (default task-5) at org.jboss.weld.module.web.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40)
> 16:58:45,504 ERROR [stderr] (default task-5) at org.jboss.weld.module.web.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50)
> 16:58:45,504 ERROR [stderr] (default task-5) at javax.faces.event.MethodExpressionActionListener.processAction(MethodExpressionActionListener.java:149)
> 16:58:45,504 ERROR [stderr] (default task-5) at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
> 16:58:45,505 ERROR [stderr] (default task-5) at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:814)
> 16:58:45,505 ERROR [stderr] (default task-5) at javax.faces.component.UICommand.broadcast(UICommand.java:300)
> 16:58:45,505 ERROR [stderr] (default task-5) at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790)
> 16:58:45,505 ERROR [stderr] (default task-5) at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282)
> 16:58:45,505 ERROR [stderr] (default task-5) at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
> 16:58:45,505 ERROR [stderr] (default task-5) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> 16:58:45,505 ERROR [stderr] (default task-5) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
> 16:58:45,505 ERROR [stderr] (default task-5) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:658)
> 16:58:45,506 ERROR [stderr] (default task-5) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> 16:58:45,506 ERROR [stderr] (default task-5) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> 16:58:45,506 ERROR [stderr] (default task-5) at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
> 16:58:45,506 ERROR [stderr] (default task-5) at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
> 16:58:45,506 ERROR [stderr] (default task-5) at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
> 16:58:45,506 ERROR [stderr] (default task-5) at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
> 16:58:45,506 ERROR [stderr] (default task-5) at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:387)
> 16:58:45,507 ERROR [stderr] (default task-5) at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
> 16:58:45,507 ERROR [stderr] (default task-5) at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
> 16:58:45,507 ERROR [stderr] (default task-5) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> 16:58:45,507 ERROR [stderr] (default task-5) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> 16:58:45,507 ERROR [stderr] (default task-5) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> 16:58:45,507 ERROR [stderr] (default task-5) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> 16:58:45,507 ERROR [stderr] (default task-5) at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> 16:58:45,507 ERROR [stderr] (default task-5) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> 16:58:45,508 ERROR [stderr] (default task-5) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 16:58:45,508 ERROR [stderr] (default task-5) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 16:58:45,508 ERROR [stderr] (default task-5) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> 16:58:45,508 ERROR [stderr] (default task-5) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> 16:58:45,508 ERROR [stderr] (default task-5) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 16:58:45,508 ERROR [stderr] (default task-5) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 16:58:45,508 ERROR [stderr] (default task-5) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 16:58:45,508 ERROR [stderr] (default task-5) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> 16:58:45,509 ERROR [stderr] (default task-5) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 16:58:45,509 ERROR [stderr] (default task-5) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 16:58:45,509 ERROR [stderr] (default task-5) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 16:58:45,509 ERROR [stderr] (default task-5) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 16:58:45,509 ERROR [stderr] (default task-5) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 16:58:45,509 ERROR [stderr] (default task-5) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 16:58:45,509 ERROR [stderr] (default task-5) at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> 16:58:45,509 ERROR [stderr] (default task-5) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 16:58:45,509 ERROR [stderr] (default task-5) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 16:58:45,510 ERROR [stderr] (default task-5) at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 16:58:45,510 ERROR [stderr] (default task-5) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 16:58:45,510 ERROR [stderr] (default task-5) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 16:58:45,510 ERROR [stderr] (default task-5) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 16:58:45,510 ERROR [stderr] (default task-5) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 16:58:45,510 ERROR [stderr] (default task-5) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> 16:58:45,510 ERROR [stderr] (default task-5) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> 16:58:45,510 ERROR [stderr] (default task-5) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> 16:58:45,510 ERROR [stderr] (default task-5) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> 16:58:45,511 ERROR [stderr] (default task-5) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> 16:58:45,511 ERROR [stderr] (default task-5) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> 16:58:45,511 ERROR [stderr] (default task-5) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 16:58:45,511 ERROR [stderr] (default task-5) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 16:58:45,511 ERROR [stderr] (default task-5) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 16:58:45,511 ERROR [stderr] (default task-5) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> 16:58:45,511 ERROR [stderr] (default task-5) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> 16:58:45,511 ERROR [stderr] (default task-5) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> 16:58:45,511 ERROR [stderr] (default task-5) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> 16:58:45,511 ERROR [stderr] (default task-5) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> 16:58:45,511 ERROR [stderr] (default task-5) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> 16:58:45,511 ERROR [stderr] (default task-5) at java.lang.Thread.run(Thread.java:748){color}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10474) AMQ119012: Timed out waiting to receive initial broadcast from cluster
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10474?page=com.atlassian.jira.plugin... ]
Paul Ferraro commented on WFLY-10474:
-------------------------------------
[~eduda] Thanks - I'll monitor it.
> AMQ119012: Timed out waiting to receive initial broadcast from cluster
> ----------------------------------------------------------------------
>
> Key: WFLY-10474
> URL: https://issues.jboss.org/browse/WFLY-10474
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 13.0.0.Beta1
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: blocker-WF14
>
> In messaging HA scenarios we see that tests sometimes fail because of exception \[1\]. The exception is thrown from {{ServerLocatorImpl::createSessionFactory}} which waits until initial broadcast from cluster is received, but it is not received in 10 seconds timeout. In following scenario the issue causes split brain - both live and backup are active at the same time.
> *Scenario*
> * There are two Wildfly/Artemis servers configured as Live-Backup pair
> * Live server is killed
> * Backup server becomes new Live server
> * Live server is restarted and failback is performed
> *Expectation:* Failback performs successfully. Original Live becomes Live again and original Backup becomes Backup again.
> *Reality:* After the Live is restarted, it does not detect that there is already another active Live with the same nodeId and it activates (becomes Live) so both Live and Backup are active at the same time.
> *Technical details*
> I found out that original Live server does not detect that its Backup is active, because SharedNothingLiveActivation::isNodeIdUsed returns false. I added more logs to this method and found out that the {{false}} is returned from line \[2\] after that the exception \[1\] is thrown.
> *Investigation report*
> I tried to downgrade Artemis to {{1.5.5.jbossorg-010}} version but I hit the same issue. So the issue is not caused by recent Artemis upgrade.
> It is regression against EAP 7.1.0.GA but it is not regression against Wildfly 12.
> We see the issue only with JGroups. I tried to run the test with Netty discovery and it passed 50 times in row.
> \[1\]
> {code}
> ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT message=AMQ119012: Timed out waiting to receive initial broadcast from cluster]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:749) [artemis-core-client-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:627) [artemis-core-client-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connectNoWarnings(ServerLocatorImpl.java:633) [artemis-core-client-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation.isNodeIdUsed(SharedNothingLiveActivation.java:280) [artemis-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation.run(SharedNothingLiveActivation.java:90) [artemis-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:539) [artemis-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:485) [artemis-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:413) [artemis-jms-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:205) [wildfly-messaging-activemq-13.0.0.Beta2-SNAPSHOT.jar:13.0.0.Beta2-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:64) [wildfly-messaging-activemq-13.0.0.Beta2-SNAPSHOT.jar:13.0.0.Beta2-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:99) [wildfly-messaging-activemq-13.0.0.Beta2-SNAPSHOT.jar:13.0.0.Beta2-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_171]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_171]
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> {code}
> \[2\] https://github.com/rh-messaging/jboss-activemq-artemis/blob/465eb8733e465...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-8954:
------------------------------------
Thanks [[~nuno.godinhomatos], with regard to the pull request, in order for others to use that, you need to grant them permission by agreeing with the *mit-license* license terms. Please comment here, with whether you agree to contribute your code improvement, via the terms of the MIT liceense agreement ([http://www.opensource.org/licenses/mit-license.php]).
If you do not agree with the terms, please indicate that here as well.
Thanks,
Scott
> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
> Key: WFLY-8954
> URL: https://issues.jboss.org/browse/WFLY-8954
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Scott Marlow
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10474) AMQ119012: Timed out waiting to receive initial broadcast from cluster
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFLY-10474?page=com.atlassian.jira.plugin... ]
Erich Duda commented on WFLY-10474:
-----------------------------------
[~pferraro] I've triggered a Jenkins job \[1\] which runs the reproducer 50 times until it fails. If it fails, you can find all logs in artifacts of the run. The job runs with latest Wildfly master.
\[1\] https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-messag...
> AMQ119012: Timed out waiting to receive initial broadcast from cluster
> ----------------------------------------------------------------------
>
> Key: WFLY-10474
> URL: https://issues.jboss.org/browse/WFLY-10474
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 13.0.0.Beta1
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: blocker-WF14
>
> In messaging HA scenarios we see that tests sometimes fail because of exception \[1\]. The exception is thrown from {{ServerLocatorImpl::createSessionFactory}} which waits until initial broadcast from cluster is received, but it is not received in 10 seconds timeout. In following scenario the issue causes split brain - both live and backup are active at the same time.
> *Scenario*
> * There are two Wildfly/Artemis servers configured as Live-Backup pair
> * Live server is killed
> * Backup server becomes new Live server
> * Live server is restarted and failback is performed
> *Expectation:* Failback performs successfully. Original Live becomes Live again and original Backup becomes Backup again.
> *Reality:* After the Live is restarted, it does not detect that there is already another active Live with the same nodeId and it activates (becomes Live) so both Live and Backup are active at the same time.
> *Technical details*
> I found out that original Live server does not detect that its Backup is active, because SharedNothingLiveActivation::isNodeIdUsed returns false. I added more logs to this method and found out that the {{false}} is returned from line \[2\] after that the exception \[1\] is thrown.
> *Investigation report*
> I tried to downgrade Artemis to {{1.5.5.jbossorg-010}} version but I hit the same issue. So the issue is not caused by recent Artemis upgrade.
> It is regression against EAP 7.1.0.GA but it is not regression against Wildfly 12.
> We see the issue only with JGroups. I tried to run the test with Netty discovery and it passed 50 times in row.
> \[1\]
> {code}
> ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT message=AMQ119012: Timed out waiting to receive initial broadcast from cluster]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:749) [artemis-core-client-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:627) [artemis-core-client-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connectNoWarnings(ServerLocatorImpl.java:633) [artemis-core-client-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation.isNodeIdUsed(SharedNothingLiveActivation.java:280) [artemis-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation.run(SharedNothingLiveActivation.java:90) [artemis-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:539) [artemis-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:485) [artemis-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:413) [artemis-jms-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:205) [wildfly-messaging-activemq-13.0.0.Beta2-SNAPSHOT.jar:13.0.0.Beta2-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:64) [wildfly-messaging-activemq-13.0.0.Beta2-SNAPSHOT.jar:13.0.0.Beta2-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:99) [wildfly-messaging-activemq-13.0.0.Beta2-SNAPSHOT.jar:13.0.0.Beta2-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_171]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_171]
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> {code}
> \[2\] https://github.com/rh-messaging/jboss-activemq-artemis/blob/465eb8733e465...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10474) AMQ119012: Timed out waiting to receive initial broadcast from cluster
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10474?page=com.atlassian.jira.plugin... ]
Paul Ferraro commented on WFLY-10474:
-------------------------------------
[~eduda] Can you paste a recent link to a log for the failing test run? I am not able to reproduce the issue locally.
> AMQ119012: Timed out waiting to receive initial broadcast from cluster
> ----------------------------------------------------------------------
>
> Key: WFLY-10474
> URL: https://issues.jboss.org/browse/WFLY-10474
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 13.0.0.Beta1
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: blocker-WF14
>
> In messaging HA scenarios we see that tests sometimes fail because of exception \[1\]. The exception is thrown from {{ServerLocatorImpl::createSessionFactory}} which waits until initial broadcast from cluster is received, but it is not received in 10 seconds timeout. In following scenario the issue causes split brain - both live and backup are active at the same time.
> *Scenario*
> * There are two Wildfly/Artemis servers configured as Live-Backup pair
> * Live server is killed
> * Backup server becomes new Live server
> * Live server is restarted and failback is performed
> *Expectation:* Failback performs successfully. Original Live becomes Live again and original Backup becomes Backup again.
> *Reality:* After the Live is restarted, it does not detect that there is already another active Live with the same nodeId and it activates (becomes Live) so both Live and Backup are active at the same time.
> *Technical details*
> I found out that original Live server does not detect that its Backup is active, because SharedNothingLiveActivation::isNodeIdUsed returns false. I added more logs to this method and found out that the {{false}} is returned from line \[2\] after that the exception \[1\] is thrown.
> *Investigation report*
> I tried to downgrade Artemis to {{1.5.5.jbossorg-010}} version but I hit the same issue. So the issue is not caused by recent Artemis upgrade.
> It is regression against EAP 7.1.0.GA but it is not regression against Wildfly 12.
> We see the issue only with JGroups. I tried to run the test with Netty discovery and it passed 50 times in row.
> \[1\]
> {code}
> ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT message=AMQ119012: Timed out waiting to receive initial broadcast from cluster]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:749) [artemis-core-client-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:627) [artemis-core-client-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connectNoWarnings(ServerLocatorImpl.java:633) [artemis-core-client-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation.isNodeIdUsed(SharedNothingLiveActivation.java:280) [artemis-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.SharedNothingLiveActivation.run(SharedNothingLiveActivation.java:90) [artemis-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:539) [artemis-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:485) [artemis-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:413) [artemis-jms-server-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:205) [wildfly-messaging-activemq-13.0.0.Beta2-SNAPSHOT.jar:13.0.0.Beta2-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:64) [wildfly-messaging-activemq-13.0.0.Beta2-SNAPSHOT.jar:13.0.0.Beta2-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:99) [wildfly-messaging-activemq-13.0.0.Beta2-SNAPSHOT.jar:13.0.0.Beta2-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_171]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_171]
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.2.Final.jar:2.3.2.Final]
> {code}
> \[2\] https://github.com/rh-messaging/jboss-activemq-artemis/blob/465eb8733e465...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years