January 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6078) Add auto-create|delete-jms-queues to address-settings resource

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-6078: --------------------------------- Summary: Add auto-create|delete-jms-queues to address-settings resource Key: WFLY-6078 URL: https://issues.jboss.org/browse/WFLY-6078 Project: WildFly Issue Type: Feature Request Components: JMS Affects Versions: 10.0.0.CR5 Reporter: Jeff Mesnil Assignee: Jeff Mesnil Fix For: 10.0.0.Final -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-987) Errors in Phreak under heavy and multi threaded load

by Marco Rietveld (JIRA)

[ https://issues.jboss.org/browse/DROOLS-987?page=com.atlassian.jira.plugin... ] Marco Rietveld closed DROOLS-987. --------------------------------- Resolution: Rejected > Errors in Phreak under heavy and multi threaded load > ----------------------------------------------------- > > Key: DROOLS-987 > URL: https://issues.jboss.org/browse/DROOLS-987 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Environment: linux > Java 7 > kernel 3.16 > Reporter: Jose Cavieres > Assignee: Marco Rietveld > Attachments: jbpm-bussinesruletask-concurrent-6-3-NEW.tgz, jbpm-bussinesruletask-concurrent-6-3.tgz > > > Several threads are started, each one starts 1 jbpm process containing rule(s) task(s). > If the threads are few, everything works fine. Under heavy load nullPointerExceptions are thown most of the time, less frequently fireAllRules never ends and CPU remains at 100%. > Aparently the setFocus method used by rule tasks is related to the problem. > The most comon error is: > Caused by: java.lang.NullPointerException > at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141) > at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80) > at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteSegmentMemory(LeftInputAdapterNode.java:295) > at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteObject(LeftInputAdapterNode.java:266) > at org.drools.core.reteoo.LeftInputAdapterNode.retractLeftTuple(LeftInputAdapterNode.java:361) > at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:334) > at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317) > at org.drools.core.reteoo.EntryPointNode.propagateRetract(EntryPointNode.java:358) > at org.drools.core.phreak.PropagationEntry$Delete.execute(PropagationEntry.java:172) > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96) > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6077) Add auto-create|delete-jms-queues to address-settings resource

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-6077: --------------------------------- Summary: Add auto-create|delete-jms-queues to address-settings resource Key: WFLY-6077 URL: https://issues.jboss.org/browse/WFLY-6077 Project: WildFly Issue Type: Feature Request Components: JMS Affects Versions: 10.0.0.CR5 Reporter: Jeff Mesnil Assignee: Jeff Mesnil Fix For: 10.0.0.Final -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-987) Errors in Phreak under heavy and multi threaded load

by Marco Rietveld (JIRA)

[ https://issues.jboss.org/browse/DROOLS-987?page=com.atlassian.jira.plugin... ] Marco Rietveld commented on DROOLS-987: --------------------------------------- Hi [~jcavieres], I noticed this in the test: {code:java} RuleRuntimeEventManager ruleRuntimeEventManager = (RuleRuntimeEventManager) kSession; ruleRuntimeEventManager.addEventListener(new DefaultAgendaEventListener() { @Override public void afterRuleFlowGroupActivated(RuleFlowGroupActivatedEvent event) { kSession.fireAllRules(); } }); {code} Could you explain why you're calling {{fireAllRules()}} inside of a listener? You should never do this -- that is the cause of this problem. When you add an explanation, please feel free to reopen this Jira. > Errors in Phreak under heavy and multi threaded load > ----------------------------------------------------- > > Key: DROOLS-987 > URL: https://issues.jboss.org/browse/DROOLS-987 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Environment: linux > Java 7 > kernel 3.16 > Reporter: Jose Cavieres > Assignee: Marco Rietveld > Attachments: jbpm-bussinesruletask-concurrent-6-3-NEW.tgz, jbpm-bussinesruletask-concurrent-6-3.tgz > > > Several threads are started, each one starts 1 jbpm process containing rule(s) task(s). > If the threads are few, everything works fine. Under heavy load nullPointerExceptions are thown most of the time, less frequently fireAllRules never ends and CPU remains at 100%. > Aparently the setFocus method used by rule tasks is related to the problem. > The most comon error is: > Caused by: java.lang.NullPointerException > at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141) > at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80) > at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteSegmentMemory(LeftInputAdapterNode.java:295) > at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteObject(LeftInputAdapterNode.java:266) > at org.drools.core.reteoo.LeftInputAdapterNode.retractLeftTuple(LeftInputAdapterNode.java:361) > at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:334) > at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317) > at org.drools.core.reteoo.EntryPointNode.propagateRetract(EntryPointNode.java:358) > at org.drools.core.phreak.PropagationEntry$Delete.execute(PropagationEntry.java:172) > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96) > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1335) Allow disabling audit log rotation

by Tomas Hofman (JIRA)

Tomas Hofman created WFCORE-1335: ------------------------------------ Summary: Allow disabling audit log rotation Key: WFCORE-1335 URL: https://issues.jboss.org/browse/WFCORE-1335 Project: WildFly Core Issue Type: Bug Components: Logging Affects Versions: 2.0.7.Final Reporter: Tomas Hofman Assignee: Tomas Hofman https://bugzilla.redhat.com/show_bug.cgi?id=1301554 org.jboss.as.controller.audit.FileAuditLogHandler always rotates audit-log.log at startup/reload. An option to disable log rotation is necessary. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1334) Allow disabling audit log rotation

by Tomas Hofman (JIRA)

Tomas Hofman created WFCORE-1334: ------------------------------------ Summary: Allow disabling audit log rotation Key: WFCORE-1334 URL: https://issues.jboss.org/browse/WFCORE-1334 Project: WildFly Core Issue Type: Bug Components: Logging Affects Versions: 2.0.7.Final Reporter: Tomas Hofman Assignee: Tomas Hofman https://bugzilla.redhat.com/show_bug.cgi?id=1301554 org.jboss.as.controller.audit.FileAuditLogHandler always rotates audit-log.log at startup/reload. An option to disable log rotation is necessary. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1202) LDAP authentication/authorization fails due to making unneeded role lookup requests

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1202?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1202: ------------------------------------------------- Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1301732|https://bugzilla.redhat.com/show_bug.cgi?id=1301732] from NEW to ASSIGNED > LDAP authentication/authorization fails due to making unneeded role lookup requests > ----------------------------------------------------------------------------------- > > Key: WFCORE-1202 > URL: https://issues.jboss.org/browse/WFCORE-1202 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Brad Maxwell > Assignee: Derek Horton > Fix For: 2.0.5.CR1 > > > LDAP authentication/authorization fails due to making unneeded role lookup requests -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1008) KieServer to update container for SNAPSHOT kjar

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1008?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-1008: ------------------------------------- I am not sure of what you're asking here. I guess you're talking about the maven default behaviour of only fetching SNAPSHOTS once per day, but if this is the case I think you can configure maven to enforce of checking SNAPSHOTs at each request. Please let me know if this is case or try to better clarify this ticket. > KieServer to update container for SNAPSHOT kjar > ----------------------------------------------- > > Key: DROOLS-1008 > URL: https://issues.jboss.org/browse/DROOLS-1008 > Project: Drools > Issue Type: Feature Request > Components: kie server > Affects Versions: 6.2.0.Final, 6.3.0.Final > Reporter: Andrew Collins > Assignee: Mario Fusco > Attachments: snapshot_kjar_reproducer.patch > > > When a kjar is a snapshot version, kie-server will not react to new snapshot versions deployed to a remote artifact repository. The remote artifact repository is only queried the first time after JVM startup. Updating a KieContainer to a newer snapshot version is only possible through use of the KieScanner, which will both fetch the new artifact from the remote repository, and reload the kmodule in the KieServer JVM. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6076) CLI deployment of WAR exploded JSF2.2 applications fails with exceptions

by Miroslav Pavleski (JIRA)

Miroslav Pavleski created WFLY-6076: --------------------------------------- Summary: CLI deployment of WAR exploded JSF2.2 applications fails with exceptions Key: WFLY-6076 URL: https://issues.jboss.org/browse/WFLY-6076 Project: WildFly Issue Type: Bug Components: JSF Affects Versions: 10.0.0.CR5 Reporter: Miroslav Pavleski Assignee: Farah Juma Attachments: cli.log, console.log In 9.0.2 FINAL and prior (8.1, 8.2) deploying an exploded WAR using the CLI was working fine. This kind of deployment has benefits during development as the static resources are updated on-save. The problem occurs probably due JSF initialization, see the attachments. Deployment using mvn wildfly:deploy works fine. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-987) Errors in Phreak under heavy and multi threaded load

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-987?page=com.atlassian.jira.plugin... ] Mario Fusco commented on DROOLS-987: ------------------------------------ Marco, I'm giving a second look at this and in reality what is reentrant is this line in the DefaultSignalManager org.jbpm.process.instance.event.DefaultSignalManager.signalEvent(DefaultSignalManager.java:74) I suspect this is wrong anyway even if I cannot be sure that this is also causing the reported error. > Errors in Phreak under heavy and multi threaded load > ----------------------------------------------------- > > Key: DROOLS-987 > URL: https://issues.jboss.org/browse/DROOLS-987 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Environment: linux > Java 7 > kernel 3.16 > Reporter: Jose Cavieres > Assignee: Marco Rietveld > Attachments: jbpm-bussinesruletask-concurrent-6-3-NEW.tgz, jbpm-bussinesruletask-concurrent-6-3.tgz > > > Several threads are started, each one starts 1 jbpm process containing rule(s) task(s). > If the threads are few, everything works fine. Under heavy load nullPointerExceptions are thown most of the time, less frequently fireAllRules never ends and CPU remains at 100%. > Aparently the setFocus method used by rule tasks is related to the problem. > The most comon error is: > Caused by: java.lang.NullPointerException > at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141) > at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80) > at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteSegmentMemory(LeftInputAdapterNode.java:295) > at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteObject(LeftInputAdapterNode.java:266) > at org.drools.core.reteoo.LeftInputAdapterNode.retractLeftTuple(LeftInputAdapterNode.java:361) > at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:334) > at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317) > at org.drools.core.reteoo.EntryPointNode.propagateRetract(EntryPointNode.java:358) > at org.drools.core.phreak.PropagationEntry$Delete.execute(PropagationEntry.java:172) > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96) > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2016