[JBoss JIRA] (JGRP-2316) DNS_PING is not using correct ports with SRV based service discovery
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2316?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2316:
--------------------------------
Thanks for the confirmation!
> DNS_PING is not using correct ports with SRV based service discovery
> --------------------------------------------------------------------
>
> Key: JGRP-2316
> URL: https://issues.jboss.org/browse/JGRP-2316
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Reporter: dmcnair
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.16
>
>
> This is a follow-up to JGRP-2296 - which changed `DefaultDNSResolver.java` to preserve the port for SRV records. While that change is working as desired, `DNS_PING.java` is not using the port when doing member discovery.
> Here are the log entries using *4.0.15*
> {noformat}
> 2018-11-29 21:37:41,561 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) Entries collected from DNS (in 5 ms): [172.29.11.50:27106, 172.29.11.50:27105]
> 2018-11-29 21:37:41,562 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) 982d38761cba: sending discovery requests to hosts [172.29.11.50:27106, 172.29.11.50:27105] on ports [7600 .. 7600]
> {noformat}
> Since the port was found via the SRV record, it should be used instead of the *transportPort* port.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11374) Master Artemis in Wildfly 10.1.0.Final is not announcing backup when restarted
by Srinivas ev (Jira)
[ https://issues.jboss.org/browse/WFLY-11374?page=com.atlassian.jira.plugin... ]
Srinivas ev commented on WFLY-11374:
------------------------------------
Sure [~mnovak], I will do it today. Thanks,
> Master Artemis in Wildfly 10.1.0.Final is not announcing backup when restarted
> ------------------------------------------------------------------------------
>
> Key: WFLY-11374
> URL: https://issues.jboss.org/browse/WFLY-11374
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.1.0.Final
> Reporter: Srinivas ev
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: active standalone full ha.xml, master and slave log samples on startup.txt, master restart.txt, master shutdown.txt, master-server-linux.log, master-server-windows.log, master.xml, rotateserver_active.log, rotateserver_active.log, rotateserver_backup.log, rotateserver_slave.log, slave standalone full ha.xml, slave-server-linux.log, slave-server-windows.log, slave.xml
>
>
> I have 2 wildfly servers acting as artemis master and slave. I am expecting failback and replication and the related configurations are done for this to work.
> This is working as expected when I have the setup in Windows. Failing in linux RHEL 7.3 machine.
> master in standalone-full-ha.xml - refer master.xml
> slave in standalone-full-ha.xml - refer slave.xml
> In the startup script, I am passing all the values for placeholders of my server host ip's accordingly.
> Test scenario -
> 1. Bring master up.
> 2. Bring slave up.
> 3. slave will announce the backup. (AMQ221031: backup announced).
> 4. Make master down.
> 5. Replication is success.
> 6. Slave is acting as master/live.
> 7. Make master up.
> Issue - master is unable to announce the backup and starts normally as a standalone wildfly.
> This backup announcement works fine in windows and failover also works as expected.
> Please let me know if anything specific required along with this details.
> Artemis jar version - artemis-*****-1.1.0.wildfly-017.jar
> in path - /opt/aor/${my project}/wildfly/modules/system/layers/base/org/apache/activemq/artemis/main
> Few logs I found which may be impacting and I am not clear -
> 1.2018-11-21 14:28:07,238 TRACE [org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionBridge] (Thread-18 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@38e819b6-2112524495)) Setting up bridge between TransportConfiguration(name=http-connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEnabled=true&httpPpgradeEndpoint=http-acceptor&port=12080&host=135-250-139-30 and ServerLocatorImpl [initialConnectors=[TransportConfiguration(name=http-connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEnabled=true&httpPpgradeEndpoint=http-acceptor&port=12080&host=135-250-139-41], discoveryGroupConfiguration=null]: java.lang.Exception: trace
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionBridge.<init>(ClusterConnectionBridge.java:129)
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl.createNewRecord(ClusterConnectionImpl.java:778)
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl.nodeUP(ClusterConnectionImpl.java:698)
> at org.apache.activemq.artemis.core.client.impl.Topology$1.run(Topology.java:264)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:103)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 2.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11481) EL expressions that contain unnecessary parentheses fail
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11481?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-11481:
-----------------------------------------
Probably this:
https://github.com/jboss/uel/blob/master/impl/pom.xml
> EL expressions that contain unnecessary parentheses fail
> --------------------------------------------------------
>
> Key: WFLY-11481
> URL: https://issues.jboss.org/browse/WFLY-11481
> Project: WildFly
> Issue Type: Bug
> Reporter: Teresa Miyar
> Assignee: Teresa Miyar
> Priority: Major
> Labels: el-expresion
> Attachments: helloworld.war
>
>
> EL with unnecessary parentheses fail. For instance:
> {code}
> <c:set var = "i" scope = "session" value = "1"/>
> <c:if test="${(i) == '1'}">
> <p>i is: <c:out value = "${i}"/><p>
> </c:if>
> {code}
> The root exception clarified by byteman is:
> {code}
> 15:16:51,903 INFO [stdout] (http_8080 task-1) ----------------------->ParseException.init
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ParseException.<init>(ParseException.java:179)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.generateParseException(ELParser.java:2963)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.jj_consume_token(ELParser.java:2845)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.LambdaExpression(ELParser.java:295)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.Assignment(ELParser.java:226)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.SemiColon(ELParser.java:181)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.Expression(ELParser.java:174)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.DynamicExpression(ELParser.java:146)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.CompositeExpression(ELParser.java:43)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.lang.ExpressionBuilder.createNodeInternal(ExpressionBuilder.java:182)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.lang.ExpressionBuilder.build(ExpressionBuilder.java:237)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.lang.ExpressionBuilder.createValueExpression(ExpressionBuilder.java:295)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.ExpressionFactoryImpl.createValueExpression(ExpressionFactoryImpl.java:112)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$JspAttribute.validateEL(Node.java:2151)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Validator$ValidateVisitor.getJspAttribute(Validator.java:1400)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Validator$ValidateVisitor.checkXmlAttributes(Validator.java:1204)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:855)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1535)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2375)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2427)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2433)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$Root.accept(Node.java:464)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2375)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1834)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:218)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Compiler.compile(Compiler.java:354)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Compiler.compile(Compiler.java:334)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Compiler.compile(Compiler.java:321)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:652)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> {code}
> Parser seems confused as if there's a Lamda expression to resolve. Seems tomcat had a similar issue:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=56179
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11481) EL expressions that contain unnecessary parentheses fail
by Stuart Douglas (Jira)
[ https://issues.jboss.org/browse/WFLY-11481?page=com.atlassian.jira.plugin... ]
Stuart Douglas commented on WFLY-11481:
---------------------------------------
I am not sure where this comes from.
> EL expressions that contain unnecessary parentheses fail
> --------------------------------------------------------
>
> Key: WFLY-11481
> URL: https://issues.jboss.org/browse/WFLY-11481
> Project: WildFly
> Issue Type: Bug
> Reporter: Teresa Miyar
> Assignee: Teresa Miyar
> Priority: Major
> Labels: el-expresion
> Attachments: helloworld.war
>
>
> EL with unnecessary parentheses fail. For instance:
> {code}
> <c:set var = "i" scope = "session" value = "1"/>
> <c:if test="${(i) == '1'}">
> <p>i is: <c:out value = "${i}"/><p>
> </c:if>
> {code}
> The root exception clarified by byteman is:
> {code}
> 15:16:51,903 INFO [stdout] (http_8080 task-1) ----------------------->ParseException.init
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ParseException.<init>(ParseException.java:179)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.generateParseException(ELParser.java:2963)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.jj_consume_token(ELParser.java:2845)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.LambdaExpression(ELParser.java:295)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.Assignment(ELParser.java:226)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.SemiColon(ELParser.java:181)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.Expression(ELParser.java:174)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.DynamicExpression(ELParser.java:146)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.CompositeExpression(ELParser.java:43)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.lang.ExpressionBuilder.createNodeInternal(ExpressionBuilder.java:182)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.lang.ExpressionBuilder.build(ExpressionBuilder.java:237)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.lang.ExpressionBuilder.createValueExpression(ExpressionBuilder.java:295)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.ExpressionFactoryImpl.createValueExpression(ExpressionFactoryImpl.java:112)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$JspAttribute.validateEL(Node.java:2151)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Validator$ValidateVisitor.getJspAttribute(Validator.java:1400)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Validator$ValidateVisitor.checkXmlAttributes(Validator.java:1204)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:855)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1535)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2375)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2427)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2433)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$Root.accept(Node.java:464)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2375)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1834)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:218)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Compiler.compile(Compiler.java:354)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Compiler.compile(Compiler.java:334)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Compiler.compile(Compiler.java:321)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:652)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> {code}
> Parser seems confused as if there's a Lamda expression to resolve. Seems tomcat had a similar issue:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=56179
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11481) EL expressions that contain unnecessary parentheses fail
by Stuart Douglas (Jira)
[ https://issues.jboss.org/browse/WFLY-11481?page=com.atlassian.jira.plugin... ]
Stuart Douglas moved UNDERTOW-1454 to WFLY-11481:
-------------------------------------------------
Project: WildFly (was: Undertow)
Key: WFLY-11481 (was: UNDERTOW-1454)
Component/s: (was: Servlet)
> EL expressions that contain unnecessary parentheses fail
> --------------------------------------------------------
>
> Key: WFLY-11481
> URL: https://issues.jboss.org/browse/WFLY-11481
> Project: WildFly
> Issue Type: Bug
> Reporter: Teresa Miyar
> Assignee: Teresa Miyar
> Priority: Major
> Labels: el-expresion
> Attachments: helloworld.war
>
>
> EL with unnecessary parentheses fail. For instance:
> {code}
> <c:set var = "i" scope = "session" value = "1"/>
> <c:if test="${(i) == '1'}">
> <p>i is: <c:out value = "${i}"/><p>
> </c:if>
> {code}
> The root exception clarified by byteman is:
> {code}
> 15:16:51,903 INFO [stdout] (http_8080 task-1) ----------------------->ParseException.init
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ParseException.<init>(ParseException.java:179)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.generateParseException(ELParser.java:2963)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.jj_consume_token(ELParser.java:2845)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.LambdaExpression(ELParser.java:295)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.Assignment(ELParser.java:226)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.SemiColon(ELParser.java:181)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.Expression(ELParser.java:174)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.DynamicExpression(ELParser.java:146)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.parser.ELParser.CompositeExpression(ELParser.java:43)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.lang.ExpressionBuilder.createNodeInternal(ExpressionBuilder.java:182)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.lang.ExpressionBuilder.build(ExpressionBuilder.java:237)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.lang.ExpressionBuilder.createValueExpression(ExpressionBuilder.java:295)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) com.sun.el.ExpressionFactoryImpl.createValueExpression(ExpressionFactoryImpl.java:112)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$JspAttribute.validateEL(Node.java:2151)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Validator$ValidateVisitor.getJspAttribute(Validator.java:1400)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Validator$ValidateVisitor.checkXmlAttributes(Validator.java:1204)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:855)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1535)
> 15:16:51,904 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2375)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2427)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2433)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$Root.accept(Node.java:464)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2375)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1834)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:218)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Compiler.compile(Compiler.java:354)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Compiler.compile(Compiler.java:334)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.compiler.Compiler.compile(Compiler.java:321)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:652)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347)
> 15:16:51,905 INFO [stdout] (http_8080 task-1) javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> {code}
> Parser seems confused as if there's a Lamda expression to resolve. Seems tomcat had a similar issue:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=56179
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (JGRP-2316) DNS_PING is not using correct ports with SRV based service discovery
by dmcnair (Jira)
[ https://issues.jboss.org/browse/JGRP-2316?page=com.atlassian.jira.plugin.... ]
dmcnair commented on JGRP-2316:
-------------------------------
[~belaban]- I've confirmed that your change solves the problem! Thanks for the discussion and quick response.
> DNS_PING is not using correct ports with SRV based service discovery
> --------------------------------------------------------------------
>
> Key: JGRP-2316
> URL: https://issues.jboss.org/browse/JGRP-2316
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Reporter: dmcnair
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.16
>
>
> This is a follow-up to JGRP-2296 - which changed `DefaultDNSResolver.java` to preserve the port for SRV records. While that change is working as desired, `DNS_PING.java` is not using the port when doing member discovery.
> Here are the log entries using *4.0.15*
> {noformat}
> 2018-11-29 21:37:41,561 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) Entries collected from DNS (in 5 ms): [172.29.11.50:27106, 172.29.11.50:27105]
> 2018-11-29 21:37:41,562 DEBUG [org.jgroups.protocols.dns.DNS_PING] (thread-4,null,null) 982d38761cba: sending discovery requests to hosts [172.29.11.50:27106, 172.29.11.50:27105] on ports [7600 .. 7600]
> {noformat}
> Since the port was found via the SRV record, it should be used instead of the *transportPort* port.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (DROOLS-3413) CME in DefaultAgenda.evaluateEagerList
by Will Keaney (Jira)
[ https://issues.jboss.org/browse/DROOLS-3413?page=com.atlassian.jira.plugi... ]
Will Keaney closed DROOLS-3413.
-------------------------------
Resolution: Out of Date
> CME in DefaultAgenda.evaluateEagerList
> --------------------------------------
>
> Key: DROOLS-3413
> URL: https://issues.jboss.org/browse/DROOLS-3413
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.Final
> Environment: RHEL 6.10 x86_64
> Drools embedded in OpenNMS Meridian 2017.1.5.
> Reporter: Will Keaney
> Assignee: Mario Fusco
> Priority: Major
>
> I have a KieSession that runs in Stream processing mode, which is throwing frequent ConcurrentModificationExceptions in evaluateEagerList:
> {code}Exception in thread "FireTask" java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> at java.util.ArrayList$Itr.next(ArrayList.java:851)
> at org.drools.core.phreak.PhreakFromNode.doLeftUpdates(PhreakFromNode.java:176)
> at org.drools.core.phreak.PhreakFromNode.doNode(PhreakFromNode.java:64)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:355)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:301)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:136)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:94)
> at org.drools.core.phreak.RuleExecutor.evaluateNetwork(RuleExecutor.java:65)
> at org.drools.core.common.DefaultAgenda.evaluateEagerList(DefaultAgenda.java:983)
> at org.drools.core.phreak.RuleExecutor.haltRuleFiring(RuleExecutor.java:233)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:138)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:970)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1312)
> at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1232)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1398)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1377)
> at org.opennms.netmgt.correlation.drools.DroolsCorrelationEngine.lambda$initialize$2(DroolsCorrelationEngine.java:217)
> at java.lang.Thread.run(Thread.java:745){code}
> Many of the rules in this KB have {{no-loop true}}.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (DROOLS-3413) CME in DefaultAgenda.evaluateEagerList
by Will Keaney (Jira)
[ https://issues.jboss.org/browse/DROOLS-3413?page=com.atlassian.jira.plugi... ]
Will Keaney commented on DROOLS-3413:
-------------------------------------
I missed that the type of {{queries}} was changed to a {{ConcurrentHashMap}} in recent versions, so this is fixed in the 7.7.x branch.
> CME in DefaultAgenda.evaluateEagerList
> --------------------------------------
>
> Key: DROOLS-3413
> URL: https://issues.jboss.org/browse/DROOLS-3413
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.Final
> Environment: RHEL 6.10 x86_64
> Drools embedded in OpenNMS Meridian 2017.1.5.
> Reporter: Will Keaney
> Assignee: Mario Fusco
> Priority: Major
>
> I have a KieSession that runs in Stream processing mode, which is throwing frequent ConcurrentModificationExceptions in evaluateEagerList:
> {code}Exception in thread "FireTask" java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> at java.util.ArrayList$Itr.next(ArrayList.java:851)
> at org.drools.core.phreak.PhreakFromNode.doLeftUpdates(PhreakFromNode.java:176)
> at org.drools.core.phreak.PhreakFromNode.doNode(PhreakFromNode.java:64)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:355)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:301)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:136)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:94)
> at org.drools.core.phreak.RuleExecutor.evaluateNetwork(RuleExecutor.java:65)
> at org.drools.core.common.DefaultAgenda.evaluateEagerList(DefaultAgenda.java:983)
> at org.drools.core.phreak.RuleExecutor.haltRuleFiring(RuleExecutor.java:233)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:138)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:970)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1312)
> at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1232)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1398)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1377)
> at org.opennms.netmgt.correlation.drools.DroolsCorrelationEngine.lambda$initialize$2(DroolsCorrelationEngine.java:217)
> at java.lang.Thread.run(Thread.java:745){code}
> Many of the rules in this KB have {{no-loop true}}.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months