[JBoss JIRA] (WFLY-5638) "Buffer was already freed" error from http request processing
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5638?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-5638.
----------------------------------
Resolution: Out of Date
> "Buffer was already freed" error from http request processing
> -------------------------------------------------------------
>
> Key: WFLY-5638
> URL: https://issues.jboss.org/browse/WFLY-5638
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 9.0.1.Final
> Reporter: Arto Huusko
> Assignee: Stuart Douglas
> Attachments: stacktrace.txt
>
>
> Undertow causes XNIO exception "Buffer was already freed" during response write, possibly due to premature client close.
> I suspect this may also cause the socket to leak, because the number of "Buffer was already freed" messages in widlfly server.log corresponds to the number of leaked sockets in the lsof command output for the wildfly process (seen as sockets with "can't identify protocol" description).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (WFLY-5932) Invalidating a session of an SSO on a different node than where the session was created does not logout the user
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5932?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-5932:
--------------------------------------
I think this should fix the problem: https://github.com/undertow-io/undertow/compare/master...stuartwdouglas:s...
Unfortunately I am having trouble getting a reproducer to work. [~rjanik] would you be able to see if this commit fixes it?
> Invalidating a session of an SSO on a different node than where the session was created does not logout the user
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5932
> URL: https://issues.jboss.org/browse/WFLY-5932
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.CR5
> Reporter: Richard Janík
> Assignee: Stuart Douglas
> Priority: Blocker
>
> See steps to reproduce for description. Additional scenario with a failover where we don't need to authenticate with the last request (but where we should be required to authenticate):
> * Access A1, authenticate, fail A1 (e.g. shutdown the server), access A2, invalidate session on A2, access A2
> Scenarios where the SSO context is destroyed (where we need to authenticate with the last request as expected):
> * Access A1, authenticate, invalidate session on A1, access A1
> * Access A1, authenticate, access A2, invalidate session on A1, access A1
> Possibly related to JBEAP-1228, JBEAP-1282. Note that we always only have a single session bound to an SSO. I'm not flagging this as a blocker, since the issue usually doesn't manifest thanks to sticky sessions on a load balancer.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (JGRP-2007) Adapt code to use new Java 8 features
by Johno Crawford (JIRA)
[ https://issues.jboss.org/browse/JGRP-2007?page=com.atlassian.jira.plugin.... ]
Johno Crawford commented on JGRP-2007:
--------------------------------------
Consider using the following pattern in hot path / high performance code areas instead of for loops.
{code}
final int size = futures.size();
for (int i = 0; i < size; i ++) {
futures.get(i).setFailure(cause);
...
{code}
using a for loop eg. for (ChannelFuture future : futures) { implicitly creates an Iterator, which will generate garbage to be collected. JIT's escape analysis should be able to get rid of it once it kicks in, but the first 10.000 iterations will get a penalty.
> Adapt code to use new Java 8 features
> -------------------------------------
>
> Key: JGRP-2007
> URL: https://issues.jboss.org/browse/JGRP-2007
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> E.g replace loops for forEach() etc
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (JASSIST-260) Stack frame corruption after writing to attribute on injected after method
by Rafael Campos (JIRA)
[ https://issues.jboss.org/browse/JASSIST-260?page=com.atlassian.jira.plugi... ]
Rafael Campos updated JASSIST-260:
----------------------------------
Steps to Reproduce:
Stack frame corruption after writing to attribute contain on class that contains method with injected code via
{code:java}
CtMethod.insertAfter(String src)
{code}
This writing happens inside of the injected code src it self.
Example:
{code:java}
public class Animal {
public String ret;
public AnimalRoles(){
ret = "Before";
}
public String hello() {
return ret;
}
public String die(String age) {
return "";
}
}
{code}
{code:java}
// Some how get the method hello from Animal into a var name methodHello
methodHello.insertAfter("this.ret = \"After\";");
{code}
{code:java}
// Call the method hello in a fresh Animal instance
Animal a = new Animal();
System.out.println(a.hello());
System.out.println(a.ret);
{code}
Result:
Before
After
Expected:
After
After
Debugging the program a in the method hello it is possible to observe the following message:
"com.sun.jdi.InternalException: Got error code in repIy:35 occurred retrieving ‘this' from stack frame."
!Image1.png|thumbnail!
Tried several work arounds but basically the problem is that the newly written data can not be read at the return statement. No workaround found so far.
Also tested with previous versions of javaassist from 3.12.1.GA until 3.20.0GA and all yield the same result.
Tried search the web for similar issues but with very little luck. Just some cryptic message with some weird workarounds that I could not get to work by any means.
was:
Stack frame corruption after writing to attribute contain on class that contains method with injected code via
{code:java}
CtMethod.insertAfter(String src)
{code}
This writing happens inside of the injected code src it self.
Example:
{code:java}
public class Animal {
public String ret;
public AnimalRoles(){
ret = "Before";
}
public String hello() {
return ret;
}
public String die(String age) {
return "";
}
}
{code}
{code:java}
// Somehow get the method hello from Animal into a var name methodHello
method.insertAfter("this.ret = \"After\";");
{code}
{code:java}
// Call the method hello in a fresh Animal instance
Animal a = new Animal();
System.out.println(a.hello());
System.out.println(a.ret);
{code}
Result:
Before
After
Expected:
After
After
Debugging the program a in the method hello it is possible to observe the following message:
"com.sun.jdi.InternalException: Got error code in repIy:35 occurred retrieving ‘this' from stack frame."
!Image1.png|thumbnail!
Tried several work arounds but basically the problem is that the newly written data can not be read at the return statement. No workaround found so far.
Also tested with previous versions of javaassist from 3.12.1.GA until 3.20.0GA and all yield the same result.
Tried search the web for similar issues but with very little luck. Just some cryptic message with some weird workarounds that I could not get to work by any means.
> Stack frame corruption after writing to attribute on injected after method
> --------------------------------------------------------------------------
>
> Key: JASSIST-260
> URL: https://issues.jboss.org/browse/JASSIST-260
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: Using java 1.8, also tested with java 1.7 same behavior on eclipse Version: Mars.1 Release (4.5.1) on windows 7 x64 bits.
> Reporter: Rafael Campos
> Assignee: Shigeru Chiba
> Priority: Minor
> Attachments: Image1.png
>
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (WFLY-678) RichFaces 4 application fails with ELException
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-678?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry resolved WFLY-678.
-----------------------------------
Resolution: Rejected
Thanks, [~yersan]. I'm resolving this per your inputs.
> RichFaces 4 application fails with ELException
> ----------------------------------------------
>
> Key: WFLY-678
> URL: https://issues.jboss.org/browse/WFLY-678
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Environment: Jenkins build 1402
> Reporter: Juergen Zimmermann
> Fix For: Awaiting Volunteers
>
> Attachments: testcase-src.zip, testcase.ear.zip, WILDFLY-678.zip
>
>
> I'm migrating an EAR from JBoss 6 to 7. The Web module is based on RichFaces 4 and Weld. However, I'm getting the stacktrace below. I'll attach a testcase.
> Stacktrace:
> javax.el.ELException: Cannot convert testcase.PasswordGroup of type class java.lang.String to class [Ljava.lang.Class;
> at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:470)
> at org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:46)
> at org.jboss.weld.util.el.ForwardingExpressionFactory.coerceToType(ForwardingExpressionFactory.java:37)
> at com.sun.faces.facelets.tag.BeanPropertyTagRule$LiteralPropertyMetadata.applyMetadata(BeanPropertyTagRule.java:88)
> at com.sun.faces.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:81)
> at javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:129)
> at javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:102)
> at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.setAttributes(BehaviorsAddingComponentHandlerWrapper.java:115)
> at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.doNewComponentActions(ComponentTagHandlerDelegateImpl.java:402)
> at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:159)
> at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
> at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
> at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
> at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
> at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
> at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
> at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
> at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:82)
> at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:152)
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:744)
> at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:100)
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:313)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
> at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893)
> at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> at java.lang.Thread.run(Thread.java:662)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (WFLY-678) RichFaces 4 application fails with ELException
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-678?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated WFLY-678:
----------------------------------
Fix Version/s: (was: Awaiting Volunteers)
> RichFaces 4 application fails with ELException
> ----------------------------------------------
>
> Key: WFLY-678
> URL: https://issues.jboss.org/browse/WFLY-678
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Environment: Jenkins build 1402
> Reporter: Juergen Zimmermann
> Attachments: testcase-src.zip, testcase.ear.zip, WILDFLY-678.zip
>
>
> I'm migrating an EAR from JBoss 6 to 7. The Web module is based on RichFaces 4 and Weld. However, I'm getting the stacktrace below. I'll attach a testcase.
> Stacktrace:
> javax.el.ELException: Cannot convert testcase.PasswordGroup of type class java.lang.String to class [Ljava.lang.Class;
> at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:470)
> at org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:46)
> at org.jboss.weld.util.el.ForwardingExpressionFactory.coerceToType(ForwardingExpressionFactory.java:37)
> at com.sun.faces.facelets.tag.BeanPropertyTagRule$LiteralPropertyMetadata.applyMetadata(BeanPropertyTagRule.java:88)
> at com.sun.faces.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:81)
> at javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:129)
> at javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:102)
> at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.setAttributes(BehaviorsAddingComponentHandlerWrapper.java:115)
> at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.doNewComponentActions(ComponentTagHandlerDelegateImpl.java:402)
> at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:159)
> at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
> at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
> at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
> at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
> at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
> at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
> at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
> at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:82)
> at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:152)
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:744)
> at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:100)
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:313)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
> at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893)
> at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> at java.lang.Thread.run(Thread.java:662)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (JASSIST-260) Stack frame corruption after writing to attribute on injected after method
by Rafael Campos (JIRA)
[ https://issues.jboss.org/browse/JASSIST-260?page=com.atlassian.jira.plugi... ]
Rafael Campos updated JASSIST-260:
----------------------------------
Steps to Reproduce:
Stack frame corruption after writing to attribute contain on class that contains method with injected code via
{code:java}
CtMethod.insertAfter(String src)
{code}
This writing happens inside of the injected code src it self.
Example:
{code:java}
public class Animal {
public String ret;
public AnimalRoles(){
ret = "Before";
}
public String hello() {
return ret;
}
public String die(String age) {
return "";
}
}
{code}
{code:java}
// Somehow get the method hello from Animal into a var name methodHello
method.insertAfter("this.ret = \"After\";");
{code}
{code:java}
// Call the method hello in a fresh Animal instance
Animal a = new Animal();
System.out.println(a.hello());
System.out.println(a.ret);
{code}
Result:
Before
After
Expected:
After
After
Debugging the program a in the method hello it is possible to observe the following message:
"com.sun.jdi.InternalException: Got error code in repIy:35 occurred retrieving ‘this' from stack frame."
!Image1.png|thumbnail!
Tried several work arounds but basically the problem is that the newly written data can not be read at the return statement. No workaround found so far.
Also tested with previous versions of javaassist from 3.12.1.GA until 3.20.0GA and all yield the same result.
Tried search the web for similar issues but with very little luck. Just some cryptic message with some weird workarounds that I could not get to work by any means.
was:
Stack frame corruption after writing to attribute contain on class that contains method with injected code via
{code:java}
CtMethod.insertAfter(String src)
{code}
This writing happens inside of the injected code src it self.
Example:
{code:java}
public class Animal {
public String ret;
public AnimalRoles(){
ret = "Before";
}
public String hello() {
return ret;
}
public String die(String age) {
return "";
}
}
{code}
{code:java}
// Somehow get the method hello from Animal into a var name methodHello
method.insertAfter("this.ret = \"After\";");
{code}
{code:java}
// Call the method hello in a fresh Animal instance
Animal a = new Animal();
System.out.println(a.hello());
System.out.println(a.ret);
{code}
Result:
Before
After
Expected:
After
After
Debugging the program a in the method hello it is possible to observe the following message:
"com.sun.jdi.InternalException: Got error code in repIy:35 occurred retrieving ‘this' from stack frame."
!Image1.png|thumbnail!
Tried several work around but basically the problem is that the newly written that can not be read at the return statement. No workaround found so far.
Also tested with previous versions of javaassist from 3.12.1.GA until 3.20.0GA and all yield the same result.
Tried search the web for similar issues but with very little luck. Just some cryptic message with some weird workarounds that I could not get to work by any means.
> Stack frame corruption after writing to attribute on injected after method
> --------------------------------------------------------------------------
>
> Key: JASSIST-260
> URL: https://issues.jboss.org/browse/JASSIST-260
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: Using java 1.8, also tested with java 1.7 same behavior on eclipse Version: Mars.1 Release (4.5.1) on windows 7 x64 bits.
> Reporter: Rafael Campos
> Assignee: Shigeru Chiba
> Priority: Minor
> Attachments: Image1.png
>
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (DROOLS-998) NullPointerException at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-998?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated DROOLS-998:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1302140, https://bugzilla.redhat.com/show_bug.cgi?id=1302141 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1302141)
> NullPointerException at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
> ---------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-998
> URL: https://issues.jboss.org/browse/DROOLS-998
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Environment: OpenJDK Runtime Environment (IcedTea 2.6.3) (7u91-2.6.3-0ubuntu0.14.04.1)
> Reporter: Christian Spurk
> Assignee: Mario Fusco
> Fix For: 6.4.0.CR1
>
>
> The following {{NullPointerException}} occurs for the following rule:
> {code}
> Exception in thread "main" 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.phreak.PhreakAccumulateNode.doLeftDeletes(PhreakAccumulateNode.java:603)
> at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:65)
> at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:565)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:536)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:372)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:332)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:166)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:123)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:142)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:978)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1292)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1294)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1260)
> at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:109)
> at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:34)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:292)
> at Test.main(Test.java:13)
> {code}
> {code}
> rule "test"
> when
> not( String() )
> accumulate(
> Long();
> sum(1)
> )
> ( Boolean() or not( Float() ) )
> then
> insert(new String());
> end
> {code}
> (Please ignore the nonsensical rule; I simply couldn't reproduce this issue in any better way without providing you my larger system where the (more complex) rule makes more sense.)
> I'm using a default KIE configuration to load the rule:
> {{kmodule.xml}}:
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <kmodule xmlns="http://jboss.org/kie/6.0.0/kmodule" />
> {code}
> {{Test.java}}:
> {code}
> import org.kie.api.KieBase;
> import org.kie.api.KieServices;
> import org.kie.api.runtime.StatelessKieSession;
> import org.kie.internal.command.CommandFactory;
> public class Test {
> public static void main(String[] args) {
> KieBase kieBase = KieServices.Factory.get().getKieClasspathContainer()
> .getKieBase();
> StatelessKieSession session = kieBase.newStatelessKieSession();
> session.execute(CommandFactory.newFireAllRules());
> }
> }
> {code}
> This issue might be related with DROOLS-987.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (DROOLS-998) NullPointerException at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-998?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-998:
------------------------------------------------
Alessandro Lazarotti <alazarot(a)redhat.com> changed the Status of [bug 1302141|https://bugzilla.redhat.com/show_bug.cgi?id=1302141] from NEW to ASSIGNED
> NullPointerException at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
> ---------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-998
> URL: https://issues.jboss.org/browse/DROOLS-998
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Environment: OpenJDK Runtime Environment (IcedTea 2.6.3) (7u91-2.6.3-0ubuntu0.14.04.1)
> Reporter: Christian Spurk
> Assignee: Mario Fusco
> Fix For: 6.4.0.CR1
>
>
> The following {{NullPointerException}} occurs for the following rule:
> {code}
> Exception in thread "main" 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.phreak.PhreakAccumulateNode.doLeftDeletes(PhreakAccumulateNode.java:603)
> at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:65)
> at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:565)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:536)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:372)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:332)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:166)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:123)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:142)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:978)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1292)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1294)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1260)
> at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:109)
> at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:34)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:292)
> at Test.main(Test.java:13)
> {code}
> {code}
> rule "test"
> when
> not( String() )
> accumulate(
> Long();
> sum(1)
> )
> ( Boolean() or not( Float() ) )
> then
> insert(new String());
> end
> {code}
> (Please ignore the nonsensical rule; I simply couldn't reproduce this issue in any better way without providing you my larger system where the (more complex) rule makes more sense.)
> I'm using a default KIE configuration to load the rule:
> {{kmodule.xml}}:
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <kmodule xmlns="http://jboss.org/kie/6.0.0/kmodule" />
> {code}
> {{Test.java}}:
> {code}
> import org.kie.api.KieBase;
> import org.kie.api.KieServices;
> import org.kie.api.runtime.StatelessKieSession;
> import org.kie.internal.command.CommandFactory;
> public class Test {
> public static void main(String[] args) {
> KieBase kieBase = KieServices.Factory.get().getKieClasspathContainer()
> .getKieBase();
> StatelessKieSession session = kieBase.newStatelessKieSession();
> session.execute(CommandFactory.newFireAllRules());
> }
> }
> {code}
> This issue might be related with DROOLS-987.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months