[JBoss JIRA] (DROOLS-1025) NPE removing a rule that contains a subnetwork
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1025?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on DROOLS-1025:
-------------------------------------------------
Ryan Zhang <rzhang(a)redhat.com> changed the Status of [bug 1298579|https://bugzilla.redhat.com/show_bug.cgi?id=1298579] from MODIFIED to ON_QA
> NPE removing a rule that contains a subnetwork
> ----------------------------------------------
>
> Key: DROOLS-1025
> URL: https://issues.jboss.org/browse/DROOLS-1025
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
>
> Removing a rule containing a subnetwork causes the following NPE:
> {code}
> java.lang.NullPointerException
> at org.drools.core.phreak.AddRemoveRule.deletePeerLeftTuple(AddRemoveRule.java:777)
> at org.drools.core.phreak.AddRemoveRule.followPeer(AddRemoveRule.java:749)
> at org.drools.core.phreak.AddRemoveRule.processLeftTuples(AddRemoveRule.java:713)
> at org.drools.core.phreak.AddRemoveRule.flushStagedTuples(AddRemoveRule.java:281)
> at org.drools.core.phreak.AddRemoveRule.removeRule(AddRemoveRule.java:153)
> at org.drools.core.reteoo.ReteooBuilder.removeTerminalNode(ReteooBuilder.java:173)
> at org.drools.core.reteoo.ReteooBuilder.removeRule(ReteooBuilder.java:163)
> at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1635)
> at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1626)
> at org.drools.core.impl.KnowledgeBaseImpl.internalRemoveRule(KnowledgeBaseImpl.java:1610)
> at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1581)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JGRP-2028) GMS sometimes ignores view bundling timeout
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2028?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2028.
----------------------------
Resolution: Done
Only waiting if wait_time_ms > 0
> GMS sometimes ignores view bundling timeout
> -------------------------------------------
>
> Key: JGRP-2028
> URL: https://issues.jboss.org/browse/JGRP-2028
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.8
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.9, 4.0
>
>
> {{GMS.ViewHandler.run()}} has this code:
> {code}
> wait_time=timeout - (System.nanoTime() - start_time);
> if(wait_time > 0 && firstRequest.canBeProcessedTogether(firstRequest)) { // JGRP-1438
> long wait_time_ms=TimeUnit.MILLISECONDS.convert(wait_time, TimeUnit.NANOSECONDS);
> queue.waitUntilClosed(wait_time_ms); // misnomer: waits until element has been added or q closed
> }
> {code}
> The problem is {{wait_time_ms}} will be {{0}} if {{0 < wait_time < 1_000_000}}. {{queue.waitUntilClosed(wait_time_ms)}} then calls {{Object.wait(0)}} and blocks forever.
> Fortunately, the joiners re-sends the {{JOIN_REQ}} message after {{GMS.join_timeout}} (3s by default), so all that happens is that the view is delayed by 3s. It does cause some random failures in tests that expect the view to form in a precise amount of time, though.
> {noformat}
> 17:04:53,034 DEBUG (ForkThread-3,InitialClusterSizeTest:) [GMS] NodeF-49399: sending JOIN(NodeF-49399) to NodeE-37644
> 17:04:53,034 TRACE (ForkThread-3,InitialClusterSizeTest:) [TCP_NIO2] NodeF-49399: sending msg to NodeE-37644, src=NodeF-49399, headers are GMS: GmsHeader[JOIN_REQ]: mbr=NodeF-49399, UNICAST3: DATA, seqno=1, first, TP: [cluster_name=ISPN]
> 17:04:53,035 DEBUG (ForkThread-4,InitialClusterSizeTest:) [GMS] NodeG-49307: sending JOIN(NodeG-49307) to NodeE-37644
> 17:04:53,035 TRACE (ForkThread-4,InitialClusterSizeTest:) [TCP_NIO2] NodeG-49307: sending msg to NodeE-37644, src=NodeG-49307, headers are GMS: GmsHeader[JOIN_REQ]: mbr=NodeG-49307, UNICAST3: DATA, seqno=1, first, TP: [cluster_name=ISPN]
> 17:04:53,060 TRACE (INT-1,NodeE-37644:) [TCP_NIO2] NodeE-37644: received [dst: NodeE-37644, src: NodeF-49399 (3 headers), size=0 bytes, flags=OOB|INTERNAL], headers are GMS: GmsHeader[JOIN_REQ]: mbr=NodeF-49399, UNICAST3: DATA, seqno=1, first, TP: [cluster_name=ISPN]
> 17:04:53,060 TRACE (INT-2,NodeE-37644:) [TCP_NIO2] NodeE-37644: received [dst: NodeE-37644, src: NodeG-49307 (3 headers), size=0 bytes, flags=OOB|INTERNAL], headers are GMS: GmsHeader[JOIN_REQ]: mbr=NodeG-49307, UNICAST3: DATA, seqno=1, first, TP: [cluster_name=ISPN]
> 17:04:53,060 TRACE (INT-1,NodeE-37644:) [UNICAST3] NodeE-37644 <-- DATA(NodeF-49399: #1, conn_id=0, first)
> 17:04:53,060 TRACE (INT-2,NodeE-37644:) [UNICAST3] NodeE-37644 <-- DATA(NodeG-49307: #1, conn_id=0, first)
> 17:04:53,061 TRACE (INT-2,NodeE-37644:) [UNICAST3] NodeE-37644: delivering NodeG-49307#1
> 17:04:53,061 TRACE (INT-1,NodeE-37644:) [UNICAST3] NodeE-37644: delivering NodeF-49399#1
> 17:04:56,035 WARN (ForkThread-3,InitialClusterSizeTest:) [GMS] NodeF-49399: JOIN(NodeF-49399) sent to NodeE-37644 timed out (after 3000 ms), on try 1
> 17:04:56,035 WARN (ForkThread-4,InitialClusterSizeTest:) [GMS] NodeG-49307: JOIN(NodeG-49307) sent to NodeE-37644 timed out (after 3000 ms), on try 1
> 17:04:56,036 DEBUG (ForkThread-3,InitialClusterSizeTest:) [GMS] NodeF-49399: sending JOIN(NodeF-49399) to NodeE-37644
> 17:04:56,036 TRACE (ForkThread-3,InitialClusterSizeTest:) [TCP_NIO2] NodeF-49399: sending msg to NodeE-37644, src=NodeF-49399, headers are GMS: GmsHeader[JOIN_REQ]: mbr=NodeF-49399, UNICAST3: DATA, seqno=2, TP: [cluster_name=ISPN]
> 17:04:56,036 DEBUG (ForkThread-4,InitialClusterSizeTest:) [GMS] NodeG-49307: sending JOIN(NodeG-49307) to NodeE-37644
> 17:04:56,036 TRACE (ForkThread-4,InitialClusterSizeTest:) [TCP_NIO2] NodeG-49307: sending msg to NodeE-37644, src=NodeG-49307, headers are GMS: GmsHeader[JOIN_REQ]: mbr=NodeG-49307, UNICAST3: DATA, seqno=2, TP: [cluster_name=ISPN]
> 17:04:56,057 TRACE (INT-1,NodeE-37644:) [TCP_NIO2] NodeE-37644: received [dst: NodeE-37644, src: NodeF-49399 (3 headers), size=0 bytes, flags=OOB|INTERNAL], headers are GMS: GmsHeader[JOIN_REQ]: mbr=NodeF-49399, UNICAST3: DATA, seqno=2, TP: [cluster_name=ISPN]
> 17:04:56,057 TRACE (INT-2,NodeE-37644:) [TCP_NIO2] NodeE-37644: received [dst: NodeE-37644, src: NodeG-49307 (3 headers), size=0 bytes, flags=OOB|INTERNAL], headers are GMS: GmsHeader[JOIN_REQ]: mbr=NodeG-49307, UNICAST3: DATA, seqno=2, TP: [cluster_name=ISPN]
> 17:04:56,057 TRACE (INT-2,NodeE-37644:) [UNICAST3] NodeE-37644: delivering NodeG-49307#2
> 17:04:56,057 TRACE (INT-1,NodeE-37644:) [UNICAST3] NodeE-37644: delivering NodeF-49399#2
> # finally
> 17:04:56,057 TRACE (ViewHandler,NodeE-37644:) [GMS] NodeE-37644: joiners=[NodeG-49307, NodeF-49399], suspected=[], leaving=[], new view: [NodeE-37644|1] (3) [NodeE-37644, NodeG-49307, NodeF-49399]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JGRP-2029) SEQUENCER locks itself from receiving messages
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2029?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2029:
---------------------------
Fix Version/s: 3.6.9
4.0
> SEQUENCER locks itself from receiving messages
> ----------------------------------------------
>
> Key: JGRP-2029
> URL: https://issues.jboss.org/browse/JGRP-2029
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.1
> Environment: two nodes cluster environment, we are using infinispan 7.1.1 with JGroups 3.6.1-FINAL inside.
> Reporter: Sean Guo
> Assignee: Bela Ban
> Fix For: 3.6.9, 4.0
>
> Attachments: filtered_threads.txt, jgroups-tcp.xml
>
>
> I attached the filtered thread dump and the jgroups-tcp.xml from one node.
> If I read the code correctly, all the threads reading message from Socket are blocked(INT-1...INT-4) and they are waiting the lock owned by #489 thread.
> Please check whether this is a bug or configuration problem. Currently we have to remove the SEQUENCER from JGroups' protocol stack.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JGRP-2029) SEQUENCER locks itself from receiving messages
by Sean Guo (JIRA)
Sean Guo created JGRP-2029:
------------------------------
Summary: SEQUENCER locks itself from receiving messages
Key: JGRP-2029
URL: https://issues.jboss.org/browse/JGRP-2029
Project: JGroups
Issue Type: Bug
Affects Versions: 3.6.1
Environment: two nodes cluster environment, we are using infinispan 7.1.1 with JGroups 3.6.1-FINAL inside.
Reporter: Sean Guo
Assignee: Bela Ban
Attachments: filtered_threads.txt, jgroups-tcp.xml
I attached the filtered thread dump and the jgroups-tcp.xml from one node.
If I read the code correctly, all the threads reading message from Socket are blocked(INT-1...INT-4) and they are waiting the lock owned by #489 thread.
Please check whether this is a bug or configuration problem. Currently we have to remove the SEQUENCER from JGroups' protocol stack.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6318) auth-constraint with role name ** does not work as specified
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6318?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-6318.
----------------------------------
Fix Version/s: 10.1.0.Final
Resolution: Done
Resolved by Undertow 1.3.19.Final
> auth-constraint with role name ** does not work as specified
> ------------------------------------------------------------
>
> Key: WFLY-6318
> URL: https://issues.jboss.org/browse/WFLY-6318
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Harald Wellmann
> Assignee: Stuart Douglas
> Fix For: 10.1.0.Final
>
>
> The following security constraint does not work as expected:
> {code}
> <security-constraint>
> <display-name>secure resource</display-name>
> <web-resource-collection>
> <web-resource-name>welcome page</web-resource-name>
> <url-pattern>/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>**</role-name>
> </auth-constraint>
> </security-constraint>
> {code}
> According to Servlet Specification 3.1, section 13.8, any authenticated user should be able to access the secured resources, but all I get is a {{Forbidden}} error page.
> Stepping through the code, I can see that {{ServletSecurityRoleHandler}} is processing a {{SingleConstraintMatch}} with {{emptyRoleSemantic == PERMIT}} and {{requiredRoles == [**]}}.
> More likely, this should be {{emptyRoleSemantic == AUTHENTICATE}} and {{requiredRoles == []}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6380) Memory leak and freeze (io.undertow.protocols.ssl.SslConduit)
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6380?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-6380.
----------------------------------
Resolution: Out of Date
Undertow 1.3.19.Final has been merged upstream. If you still see this issue with the updated Unsertow feel free to reopen.
> Memory leak and freeze (io.undertow.protocols.ssl.SslConduit)
> -------------------------------------------------------------
>
> Key: WFLY-6380
> URL: https://issues.jboss.org/browse/WFLY-6380
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Environment: JVM: Java HotSpot(TM) 64-Bit Server VM (25.74-b02, mixed mode)
> Java: version 1.8.0_74, vendor Oracle Corporation
> Java Home: /home/jboss/jdk1.8.0_74/jre
> JVM Arguments:
> -D[Standalone]
> -Xms256m
> -Xmx2048m
> -XX:MaxPermSize=512m
> -Djava.net.preferIPv4Stack=true
> -Djboss.modules.system.pkgs=org.jboss.byteman
> -Djava.awt.headless=true
> -agentlib:jdwp=transport=dt_socket,address=38787,server=y,suspend=n
> -Dorg.jboss.boot.log.file=/home/jboss/wildfly-10.0.0.Final/standalone/log/server.log
> -Dlogging.configuration=file:/home/jboss/wildfly-10.0.0.Final/standalone/configuration/logging.properties
> System properties:
> [Standalone]=
> awt.toolkit=sun.awt.X11.XToolkit
> file.encoding=UTF-8
> file.encoding.pkg=sun.io
> file.separator=/
> java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment
> java.awt.headless=true
> java.awt.printerjob=sun.print.PSPrinterJob
> java.class.path=/home/jboss/wildfly-10.0.0.Final/jboss-modules.jar
> java.class.version=52.0
> java.endorsed.dirs=/home/jboss/jdk1.8.0_74/jre/lib/endorsed
> java.ext.dirs=/home/jboss/jdk1.8.0_74/jre/lib/ext:/usr/java/packages/lib/ext
> java.home=/home/jboss/jdk1.8.0_74/jre
> java.io.tmpdir=/tmp
> java.library.path=/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
> java.naming.factory.url.pkgs=org.jboss.as.naming.interfaces:org.jboss.ejb.client.naming
> java.net.preferIPv4Stack=true
> java.protocol.handler.pkgs=org.jboss.net.protocol|org.jboss.vfs.protocol
> java.runtime.name=Java(TM) SE Runtime Environment
> java.runtime.version=1.8.0_74-b02
> java.security.auth.login.config=jar:file:/home/jboss/wildfly-10.0.0.Final/modules/system/layers/base/org/picketbox/main/picketbox-4.9.4.Final.jar!/auth.conf
> java.specification.name=Java Platform API Specification
> java.specification.vendor=Oracle Corporation
> java.specification.version=1.8
> java.util.logging.manager=org.jboss.logmanager.LogManager
> java.vendor=Oracle Corporation
> java.vendor.url=http://java.oracle.com/
> java.vendor.url.bug=http://bugreport.sun.com/bugreport/
> java.version=1.8.0_74
> java.vm.info=mixed mode
> java.vm.name=Java HotSpot(TM) 64-Bit Server VM
> java.vm.specification.name=Java Virtual Machine Specification
> java.vm.specification.vendor=Oracle Corporation
> java.vm.specification.version=1.8
> java.vm.vendor=Oracle Corporation
> java.vm.version=25.74-b02
> javax.management.builder.initial=org.jboss.as.jmx.PluggableMBeanServerBuilder
> javax.xml.datatype.DatatypeFactory=__redirected.__DatatypeFactory
> javax.xml.parsers.DocumentBuilderFactory=__redirected.__DocumentBuilderFactory
> javax.xml.parsers.SAXParserFactory=__redirected.__SAXParserFactory
> javax.xml.stream.XMLEventFactory=__redirected.__XMLEventFactory
> javax.xml.stream.XMLInputFactory=__redirected.__XMLInputFactory
> javax.xml.stream.XMLOutputFactory=__redirected.__XMLOutputFactory
> javax.xml.transform.TransformerFactory=__redirected.__TransformerFactory
> javax.xml.validation.SchemaFactory:http://www.w3.org/2001/XMLSchema=__red...
> javax.xml.xpath.XPathFactory:http://java.sun.com/jaxp/xpath/dom=__redirec...
> jboss.bind.address=0.0.0.0
> jboss.home.dir=/home/jboss/wildfly-10.0.0.Final
> jboss.host.name=cntest
> jboss.modules.dir=/home/jboss/wildfly-10.0.0.Final/modules
> jboss.modules.system.pkgs=org.jboss.byteman
> jboss.node.name=***
> jboss.qualified.host.name=***
> jboss.server.base.dir=/home/jboss/wildfly-10.0.0.Final/standalone
> jboss.server.config.dir=/home/jboss/wildfly-10.0.0.Final/standalone/configuration
> jboss.server.data.dir=/home/jboss/wildfly-10.0.0.Final/standalone/data
> jboss.server.deploy.dir=/home/jboss/wildfly-10.0.0.Final/standalone/data/content
> jboss.server.log.dir=/home/jboss/wildfly-10.0.0.Final/standalone/log
> jboss.server.name=***
> jboss.server.persist.config=true
> jboss.server.temp.dir=/home/jboss/wildfly-10.0.0.Final/standalone/tmp
> line.separator=\n
> logging.configuration=file:/home/jboss/wildfly-10.0.0.Final/standalone/configuration/logging.properties
> module.path=/home/jboss/wildfly-10.0.0.Final/modules
> org.apache.xml.security.ignoreLineBreaks=true
> org.jboss.boot.log.file=/home/jboss/wildfly-10.0.0.Final/standalone/log/server.log
> org.jboss.resolver.warning=true
> org.jboss.security.context.ThreadLocal=true
> org.xml.sax.driver=__redirected.__XMLReaderFactory
> os.arch=amd64
> os.name=Linux
> os.version=2.6.32-5-amd64
> path.separator=:
> sun.arch.data.model=64
> sun.boot.class.path=/home/jboss/jdk1.8.0_74/jre/lib/resources.jar:/home/jboss/jdk1.8.0_74/jre/lib/rt.jar:/home/jboss/jdk1.8.0_74/jre/lib/sunrsasign.jar:/home/jboss/jdk1.8.0_74/jre/lib/jsse.jar:/home/jboss/jdk1.8.0_74/jre/lib/jce.jar:/home/jboss/jdk1.8.0_74/jre/lib/charsets.jar:/home/jboss/jdk1.8.0_74/jre/lib/jfr.jar:/home/jboss/jdk1.8.0_74/jre/classes
> sun.boot.library.path=/home/jboss/jdk1.8.0_74/jre/lib/amd64
> sun.cpu.endian=little
> sun.cpu.isalist=
> sun.io.unicode.encoding=UnicodeLittle
> sun.java.command=/home/jboss/wildfly-10.0.0.Final/jboss-modules.jar -mp /home/jboss/wildfly-10.0.0.Final/modules org.jboss.as.standalone -Djboss.home.dir=/home/jboss/wildfly-10.0.0.Final -Djboss.server.base.dir=/home/jboss/wildfly-10.0.0.Final/standalone -c standalone.xml -b 0.0.0.0
> sun.java.launcher=SUN_STANDARD
> sun.jnu.encoding=UTF-8
> sun.management.compiler=HotSpot 64-Bit Tiered Compilers
> sun.nio.ch.bugLevel=
> sun.os.patch.level=unknown
> user.country=HU
> user.dir=/home/jboss/wildfly-10.0.0.Final
> user.home=/home/jboss
> user.language=hu
> user.name=jboss
> user.timezone=Europe/Budapest
> Reporter: Róbert Ihász
> Assignee: Stuart Douglas
> Priority: Critical
> Labels: memory_leak, memoryleak
> Attachments: wildfly_memory_leak.PNG
>
>
> After a time the wildfly freeze hard. Cpu work at the maximum and memory is out. Only kill -9 can stop the entire application. I tried to monitor with Java VisualVM and it seems that the io.undertow.protocols.ssl.SslConduit$1 class growns too big. I attach a print screen from VisualVm.
> The log and console out are not shown any errors.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month