[JBoss JIRA] (JBRULES-3718) java.lang.NullPointerException at org.mvel2.ast.IntSub.getReducedValueAccelerated
by Michiel Vermandel (JIRA)
Michiel Vermandel created JBRULES-3718:
------------------------------------------
Summary: java.lang.NullPointerException at org.mvel2.ast.IntSub.getReducedValueAccelerated
Key: JBRULES-3718
URL: https://issues.jboss.org/browse/JBRULES-3718
Project: JBRULES
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 5.5.0.Final
Environment: Windows 7 64bit - Java 1.7.0
Drools-planner 5.5.0.Final
-> Drools-core 5.5.0.Final
-> mvel2 2.1.3.Final
Reporter: Michiel Vermandel
Assignee: Mark Proctor
When I run my planning I get now and then the stacktrace as mentioned below.
It happens about 1 in 5 times during running a JUnit test on small amount of planning entities and problem facts.
It started after adding my last rule:
rule "tasksInSameCommunityMustBeChained"
when
$lead : Task(this==lead, period!=null, communityId!= null, $communityId : communityId)
not ( Task(this==lead, communityId == $communityId, id != $lead.id, ($lead.startPeriodId-1) <= endPeriodId && ($lead.endPeriodId+1) >= startPeriodId ) )
then
insertLogical(new IntConstraintOccurrence("tasksInSameCommunityMustBeChained", ConstraintType.NEGATIVE_HARD, Importance.chainedPeriod, $communityId, $lead, $lead.getStartPeriodId()));
end
Stack trace:
Exception in thread "Thread-1" java.lang.NullPointerException
at org.mvel2.ast.IntSub.getReducedValueAccelerated(IntSub.java:17)
at org.mvel2.compiler.ExecutableAccessor.getValue(ExecutableAccessor.java:38)
at org.mvel2.ast.Substatement.getReducedValueAccelerated(Substatement.java:44)
at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:108)
at org.mvel2.ast.And.getReducedValueAccelerated(And.java:34)
at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:113)
at org.mvel2.MVEL.executeExpression(MVEL.java:930)
at org.drools.rule.constraint.MvelConditionEvaluator.evaluate(MvelConditionEvaluator.java:70)
at org.drools.rule.constraint.MvelConditionEvaluator.ensureBranchEvaluation(MvelConditionEvaluator.java:117)
at org.drools.rule.constraint.MvelConditionEvaluator.ensureCompleteEvaluation(MvelConditionEvaluator.java:102)
at org.drools.rule.constraint.MvelConditionEvaluator.ensureCompleteEvaluation(MvelConditionEvaluator.java:90)
at org.drools.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:82)
at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:270)
at org.drools.rule.constraint.MvelConstraint.access$200(MvelConstraint.java:51)
at org.drools.rule.constraint.MvelConstraint$ConditionJitter.run(MvelConstraint.java:250)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (REMJMX-45) Memory leak when requesting attributes using JMXConnectorFactory over remoting-jmx via management interface
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/REMJMX-45?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on REMJMX-45:
----------------------------------------
To backport the fix will require a small amount of work on your part - your version only contains one version of the protocol so you only need to fix it in that location - there has been some re-factoring in the upstream version but apart from being in a different location you should be able to track down the same place the clean up code is needed.
> Memory leak when requesting attributes using JMXConnectorFactory over remoting-jmx via management interface
> -----------------------------------------------------------------------------------------------------------
>
> Key: REMJMX-45
> URL: https://issues.jboss.org/browse/REMJMX-45
> Project: Remoting JMX
> Issue Type: Bug
> Components: Connection
> Affects Versions: 1.0.3.Final
> Environment: java version "1.6.0_31"
> Reporter: Alexandre Gattiker
> Assignee: Darran Lofthouse
> Fix For: 1.0.4.Final
>
>
> Repeated remote request of JMX attributes, as performed by a Nagios plugin, causes heap space to grow to the limit and eventually the server to freeze.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (JGRP-1563) UNICAST2: first-message-lost problem
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1563?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1563.
----------------------------
Resolution: Done
Fixed by resending the first message in the retransmission task if the connection is not marked as established
> UNICAST2: first-message-lost problem
> ------------------------------------
>
> Key: JGRP-1563
> URL: https://issues.jboss.org/browse/JGRP-1563
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.2.6, 3.3
>
>
> If A sends its first message A#1 to B, but the network drops A#1, B won't be able to receive A#1 unless A sends another message.
> Even the stable task won't help: as B only sends stable messages to connected members (and A isn't), it will never send a stable message to A.
> SOLUTION:
> - Use acking for the first message
> - Continue sending the first message until it has been acked, or a configurable time period has elapsed
> - Note that we cannot cancel this task based on *membership* (view changes), as unicast messages can be sent to members outside of our view
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (REMJMX-45) Memory leak when requesting attributes using JMXConnectorFactory over remoting-jmx via management interface
by Sudhakar Pyndi (JIRA)
[ https://issues.jboss.org/browse/REMJMX-45?page=com.atlassian.jira.plugin.... ]
Sudhakar Pyndi edited comment on REMJMX-45 at 1/16/13 11:56 PM:
----------------------------------------------------------------
Thank you very much Darran.
Would you recommend taking the REMJMX-57 code fix and applying it to the remoting-jmx.1.0.5.Final source code? This memory leak issue is a huge blocker for us. We would like to get this fix in JBoss 7.1.x, so I'm wondering on the options/approach. Please advice.
was (Author: spyndi):
Thank you very much Darran.
Would you recommend taking the REMJMX-57 code fix and applying it to the remoting-jmx.1.0.5.Final source code? This memory leak issue is a huge blocker for us. We would like to get this fix in JBoss 7.1.x, so i'm wondering on the options/approach. Please advice.
> Memory leak when requesting attributes using JMXConnectorFactory over remoting-jmx via management interface
> -----------------------------------------------------------------------------------------------------------
>
> Key: REMJMX-45
> URL: https://issues.jboss.org/browse/REMJMX-45
> Project: Remoting JMX
> Issue Type: Bug
> Components: Connection
> Affects Versions: 1.0.3.Final
> Environment: java version "1.6.0_31"
> Reporter: Alexandre Gattiker
> Assignee: Darran Lofthouse
> Fix For: 1.0.4.Final
>
>
> Repeated remote request of JMX attributes, as performed by a Nagios plugin, causes heap space to grow to the limit and eventually the server to freeze.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (REMJMX-45) Memory leak when requesting attributes using JMXConnectorFactory over remoting-jmx via management interface
by Sudhakar Pyndi (JIRA)
[ https://issues.jboss.org/browse/REMJMX-45?page=com.atlassian.jira.plugin.... ]
Sudhakar Pyndi commented on REMJMX-45:
--------------------------------------
Thank you very much Darran.
Would you recommend taking the REMJMX-57 code fix and applying it to the remoting-jmx.1.0.5.Final source code? This memory leak issue is a huge blocker for us. We would like to get this fix in JBoss 7.1.x, so i'm wondering on the options/approach. Please advice.
> Memory leak when requesting attributes using JMXConnectorFactory over remoting-jmx via management interface
> -----------------------------------------------------------------------------------------------------------
>
> Key: REMJMX-45
> URL: https://issues.jboss.org/browse/REMJMX-45
> Project: Remoting JMX
> Issue Type: Bug
> Components: Connection
> Affects Versions: 1.0.3.Final
> Environment: java version "1.6.0_31"
> Reporter: Alexandre Gattiker
> Assignee: Darran Lofthouse
> Fix For: 1.0.4.Final
>
>
> Repeated remote request of JMX attributes, as performed by a Nagios plugin, causes heap space to grow to the limit and eventually the server to freeze.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (JBREM-1317) BisocketClientInvoker waits for failed clients
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/JBREM-1317?page=com.atlassian.jira.plugin... ]
Ron Sigal commented on JBREM-1317:
----------------------------------
Hi Howard,
You're right. In fact, JBossMessaging shouldn't have to make a change to compensate for a problem in Remoting. I'll take a look to see what I can do.
-Ron
> BisocketClientInvoker waits for failed clients
> ----------------------------------------------
>
> Key: JBREM-1317
> URL: https://issues.jboss.org/browse/JBREM-1317
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: callbacks
> Affects Versions: 2.5.4.SP3
> Environment: JBoss EAP 5.1.2
> Reporter: Doug Grove
> Assignee: Ron Sigal
> Priority: Minor
>
> When a client dies or is killed, the failure is actually detected in org.jboss.remoting.transport.socket.MicroSocketClientInvoker:
> (NEW ClientSocketWrapper[Socket[addr=/10.0.0.212,port=36600,localport=4458].d3e837]) got Exception: java.io.IOException: Broken pipe
> The "Broken pipe" exception means that the client has disconnected and can not return. This exception is treated in the code a retry-able, however.
> The code carries on, finally calling BisocketClientInvoker.createSocket(). This code then waits for a socket to appear in a list. I can see no way for a new socket to ever appear in the list.
> This results in the code waiting for the full duration of the configured timeout.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 3 months
[JBoss JIRA] (AS7-6345) <vault> does not have module option
by Anil Saldhana (JIRA)
[ https://issues.jboss.org/browse/AS7-6345?page=com.atlassian.jira.plugin.s... ]
Anil Saldhana reassigned AS7-6345:
----------------------------------
Assignee: Stefan Guilhen (was: Anil Saldhana)
> <vault> does not have module option
> -----------------------------------
>
> Key: AS7-6345
> URL: https://issues.jboss.org/browse/AS7-6345
> Project: Application Server 7
> Issue Type: Bug
> Components: Security
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: James Livingston
> Assignee: Stefan Guilhen
>
> The <vault> element in standalone/domain.xml takes a 'code' attribute specifying the class to use as the implementation. It does not let you specify a 'module' option like most similar elements have, and instead always loads the class from the org.picketbox module.
> The <vault> element should take a module option too.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-6345) <vault> does not have module option
by James Livingston (JIRA)
James Livingston created AS7-6345:
-------------------------------------
Summary: <vault> does not have module option
Key: AS7-6345
URL: https://issues.jboss.org/browse/AS7-6345
Project: Application Server 7
Issue Type: Bug
Components: Security
Affects Versions: 7.1.3.Final (EAP)
Reporter: James Livingston
Assignee: Anil Saldhana
The <vault> element in standalone/domain.xml takes a 'code' attribute specifying the class to use as the implementation. It does not let you specify a 'module' option like most similar elements have, and instead always loads the class from the org.picketbox module.
The <vault> element should take a module option too.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (JBAS-7882) Wrong provider code base for security provider included in packed ear
by Alvin Thompson (JIRA)
[ https://issues.jboss.org/browse/JBAS-7882?page=com.atlassian.jira.plugin.... ]
Alvin Thompson commented on JBAS-7882:
--------------------------------------
The module solution works, but it's a workaround and not a fix, and it makes your code less portable since you have to exclude the lib from your WAR/EAR.
> Wrong provider code base for security provider included in packed ear
> ---------------------------------------------------------------------
>
> Key: JBAS-7882
> URL: https://issues.jboss.org/browse/JBAS-7882
> Project: Application Server 3 4 5 and 6
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: VFS
> Affects Versions: JBossAS-5.1.0.GA, 6.0.0.M2, 6.0.0.M3, 6.0.0.Final
> Environment: Any OS, JDK 5 and 6, JBoss AS 5.1.0 and 6.0.0.M2
> Reporter: Petr H
> Assignee: Ales Justin
> Labels: base, code, nested, vfs
> Attachments: IAIKTest.ear, JBAS-7882.patch, server-default.log, server-forceVfsJar.log
>
>
> We've got applications which use the IAIK JCE provider (http://jce.iaik.tugraz.at/sic/Products/Core-Crypto-Toolkits/JCA-JCE) whose library is included directly in our application.
> On JBoss AS 5 and later, we can't use this provider as usually.
> The new VFS mechanism seems to break the path determination to the IAIK provider library (needed to determine provider code base) - it still points into the ear/war structure inside the server deploy directory but as all this is packed into one ear file, the provider verification.fails because of unsigned ear/war and thus the following exception is thrown:
> 2010-04-01 15:04:20,034 INFO [STDOUT] (http-0.0.0.0-8180-1) Provider code base: jar:file:/opt/jboss-5.1.0.GA/server/test1/deploy/IAIKTest.ear!/IAIKTestWeb.war
> ...
> 2010-04-01 15:04:20,890 ERROR [STDERR] (http-0.0.0.0-8180-1) java.lang.SecurityException: JCE cannot authenticate the provider IAIK
> 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.Cipher.getInstance(DashoA13*..)
> 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.Cipher.getInstance(DashoA13*..)
> 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at iaik.test.ControllerServlet.service(ControllerServlet.java:123)
> 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:905)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:592)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2036)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at java.lang.Thread.run(Thread.java:619)
> 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) Caused by: java.util.jar.JarException: Cannot parse jar:file:/opt/jboss-5.1.0.GA/server/test1/deploy/IAIKTest.ear!/IAIKTestWeb.war
> 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.SunJCE_c.a(DashoA13*..)
> 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.SunJCE_b.b(DashoA13*..)
> 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.SunJCE_b.a(DashoA13*..)
> 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) ... 24 more
> This works when one of tho three mentioned workarounds is used.
> The most interesting of course is the third workaround for which the code base corectly points to the temporary IAIK library instance in the java.io.tmpdir:
> 2010-04-01 15:09:51,291 INFO [STDOUT] (http-0.0.0.0-8180-1) Provider code base: file:/tmp/nestedjar2481829661547119990.tmp
> I'll attach a simple testcase ear (IAIKTest.ear) which contains an evaluation version of IAIK provider library (thanks for permission to the IAIK authors) and a simple servlet (including source) which demonstrates the problem.
> All you need to do is to have the unrestricted JCE policy files installed in your JRE and then just put the IAIKTest.ear into the deploy directory, start the JBoss instance and access the test servlet URL in browser, for example: http://localhost:8080/IAIKTestWeb/ControllerServlet
> On init (which happens on start) it will register the IAIK provider
> On service (after you access it in browser) it will attempt to get some cipher instance and here it fails.
> I'll also attach two log files covering the problem:
> - server-default.log with default server setup where the issue occurs
> - server-forceVfsJar.log with jboss.vfs.forceVfsJar=true where the issue doesn't occur
> Also I think this is more generic problem because we had similar issues, where some jar or resource location was pointing to the packed ear/war structure inside the deploy directory instead of those VFS temporary locations, with our own code (when attemting to obtain full path) and had to perform some modifications in order to make it working. The same set of workarounds could resolve these issues as well.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months