January 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-1271) MuxMessageDispatcher mutates RequestOptions leading ultimately to potential StackOverflowError

by Eric Sirianni (JIRA)

MuxMessageDispatcher mutates RequestOptions leading ultimately to potential StackOverflowError ---------------------------------------------------------------------------------------------- Key: JGRP-1271 URL: https://issues.jboss.org/browse/JGRP-1271 Project: JGroups Issue Type: Bug Affects Versions: 2.11 Environment: All Reporter: Eric Sirianni Assignee: Bela Ban The presence of 'public static final' RequestOptions SYNC and ASYNC implies strongly that RequestOptions are immutable. Otherwise, clients could be changing the meaning of these shared constants. However, MuxMessageDispatcher.cast() mutates the passed-in RequestOptions to set the RspFilter. It chains the existing RspFilter in the RequestOptions to a new one: options.setRspFilter((filter != null) ? new NoMuxHandlerRspFilter(filter) : new NoMuxHandlerRspFilter()) The result of this is that the following innocent looking code code will quickly lead to a stack overflow as the RspFilter chain in the RequestOptions.ASYNC object grows without bound: while (true) { muxMessageDispatcher.cast(dests, msg, RequestOptions.ASYNC, false); } The workaround is to create a new RequestOptions object per call to cast() : while (true) { muxMessageDispatcher.cast(dests, msg, new RequestOptions(...), false); } I recommend either: A. Deprecating the public static final RequestOptions ASYNC and SYNC fields and heavily JavaDoc'ing that clients must use a fresh RequestOptions for each send() or cast() invocation. -or- B. JavaDoc'ing the RequestOptions class as *immutable* and fixing MuxMessageDispatcher and other such JGroups blocks that mutate RequestOptions. You may wish to add a "copy constructor" to RequestOptions to facilitate this. The fix for MuxMessageDispatcher is fairly easy - just "clone" the passed-in RequestOptions and set the NoMuxHandlerRspFilter on the new RequestOptions object: < return super.cast(dests, msg, options.setRspFilter((filter != null) ? new NoMuxHandlerRspFilter(filter) : new NoMuxHandlerRspFilter()), blockForResults); --- > RequestOptions newOptions = new RequestOptions(options.getMode(), options.getTimeout(), options.getAnycasting(), options, (filter != null) ? new NoMuxHandlerRspFilter(filter) : new NoMuxHandlerRspFilter(), options.getFlags()); > return super.cast(dests, msg, newOptions), blockForResults); -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

3
6
0 / 0

[JBoss JIRA] Created: (JBRULES-2284) OutOfMemoryException at DT loading

by Sergey Vanskov (JIRA)

OutOfMemoryException at DT loading ---------------------------------- Key: JBRULES-2284 URL: https://jira.jboss.org/jira/browse/JBRULES-2284 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-decisiontables Affects Versions: 5.0.1.FINAL Environment: Core2Quad Windows XP Pro 64 Reporter: Sergey Vanskov Assignee: Mark Proctor I have created DT having 20.000 rows with 4 conditions and 1 action in CSV format and set the following parameters for JVM -Xmx3072M -XX:MaxPermSize=256M. I haveOutOfMemoryException with the following stack trace java.lang.OutOfMemoryError: Java heap space at java.lang.String.format(String.java:2558) at org.drools.lang.DroolsParserExceptionFactory.formatParserLocation(DroolsParserExceptionFactory.java:203) at org.drools.lang.DroolsParserExceptionFactory.createErrorMessage(DroolsParserExceptionFactory.java:104) at org.drools.lang.DroolsParserExceptionFactory.createDroolsException(DroolsParserExceptionFactory.java:89) at org.drools.lang.DRLParser.reportError(DRLParser.java:350) at org.antlr.runtime.BaseRecognizer.recoverFromMismatchedToken(BaseRecognizer.java:624) at org.antlr.runtime.BaseRecognizer.match(BaseRecognizer.java:115) at org.drools.lang.DRLParser.fact(DRLParser.java:9841) at org.drools.lang.DRLParser.lhs_pattern(DRLParser.java:9388) at org.drools.lang.DRLParser.pattern_source(DRLParser.java:7432) at org.drools.lang.DRLParser.lhs_unary(DRLParser.java:6582) at org.drools.lang.DRLParser.lhs_and(DRLParser.java:6229) at org.drools.lang.DRLParser.lhs_or(DRLParser.java:5877) at org.drools.lang.DRLParser.lhs(DRLParser.java:5673) at org.drools.lang.DRLParser.normal_lhs_block(DRLParser.java:5580) at org.drools.lang.DRLParser.when_part(DRLParser.java:3975) at org.drools.lang.DRLParser.rule(DRLParser.java:3769) at org.drools.lang.DRLParser.statement(DRLParser.java:993) at org.drools.lang.DRLParser.compilation_unit(DRLParser.java:484) at org.drools.compiler.DrlParser.compile(DrlParser.java:238) at org.drools.compiler.DrlParser.parse(DrlParser.java:78) at org.drools.compiler.DrlParser.parse(DrlParser.java:83) at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:275) at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:510) at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:31) .... Is 3Gb not enough for such a problem?! How may memory requirements be estimated? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

4
5
0 / 0

[JBoss JIRA] Created: (JBRULES-2297) Enable marshalling of events in drools fusion

by Maciej Prochniak (JIRA)

Enable marshalling of events in drools fusion --------------------------------------------- Key: JBRULES-2297 URL: https://jira.jboss.org/jira/browse/JBRULES-2297 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-core, drools-core (fusion) Affects Versions: 5.1.0.M1 Reporter: Maciej Prochniak Assignee: Mark Proctor Currently, when one tries to (un)marshall EventFactHandle an exception is thrown, as default marshaller recognizes only DefaultFactHandle. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

3
8
0 / 0

[JBoss JIRA] Created: (JBBOOT-116) Implement a Graceful Shutdown API and Implementation

by Andrew Lee Rubinger (JIRA)

Implement a Graceful Shutdown API and Implementation ----------------------------------------------------- Key: JBBOOT-116 URL: https://jira.jboss.org/jira/browse/JBBOOT-116 Project: JBoss Bootstrap Issue Type: Feature Request Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger As identified by the Summer 2009 AS Meeting. Requirements: * Decoupled sufficiently from other Bootstrap mechanisms as to not leak out dependencies * 2-phase event-listener registration API * May be injected into MC Beans * 1st phase is a concurrent broadcast to all subsystems which have registered: "prepare for shutdown" * When all listeners have reported "ready", fire 2nd phase: "shutdown" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

3
4
0 / 0

[JBoss JIRA] Created: (JBWEB-171) ClusteredSession.setAttribute() could report the attribute name and/or class FQN when not serializable

by James Livingston (JIRA)

ClusteredSession.setAttribute() could report the attribute name and/or class FQN when not serializable ------------------------------------------------------------------------------------------------------ Key: JBWEB-171 URL: https://jira.jboss.org/browse/JBWEB-171 Project: JBoss Web Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Cluster Affects Versions: JBossWeb-2.1.3.GA Reporter: James Livingston Assignee: Remy Maucherat Priority: Minor org.jboss.web.tomcat.service.session.ClusteredSession.setAttribute() raises an exception with the clusteredSession.setAttribute.iae message if the attribute can't be replicated (i.e. isn't Serializable or a primitive). It would be nice if it mentioned the attribute name and/or the class FQN in the error message to aid in debugging. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

2
1
0 / 0

[JBoss JIRA] Created: (JBVFS-159) Native memory leak due to ZipEntryInputStream

by Samuel Cai (JIRA)

Native memory leak due to ZipEntryInputStream --------------------------------------------- Key: JBVFS-159 URL: https://jira.jboss.org/browse/JBVFS-159 Project: JBoss VFS Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.1.2.GA Environment: Redhat (not sure what version) 2.6.9-78.ELsmp JBoss 5.1.0.GA JDK 1.6.0_20 JVM parameter: -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime -verbose:gc -Dfile.encoding=iso-8859-1 -server -Djava.net.preferIPv4Stack=true -Doracle.jdbc.V8Compatible=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Dnetworkaddress.cache.ttl=300 -Xss128k -Xmn500m -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true -XX:+PrintGCDetails -XX:PermSize=256m -XX:MaxPermSize=256m -Xms1500m -Xmx1500m -XX:+HeapDumpOnOutOfMemoryError -XX:+UseConcMarkSweepGC Reporter: Samuel Cai Assignee: John Bailey We used to use JBoss 4.2.1.GA and JDK 1.6.0_11, and trying JBoss 5.1.0.GA and JDK 1.6.0_20 these days. I found the process size is more larger than before, 2.5G~2.9G compared to 1.9G. I was thinking this was a bug of JBoss AS, then filed https://jira.jboss.org/browse/JBAS-8066 After these days investigation, I think this is a memory leak in VFS, maybe only happen on our specific environment. I tried a change on class org.jboss.virtual.plugins.context.zip.ZipFileWrapper, method openStream: From: ZipEntryInputStream zis = new ZipEntryInputStream(this, is); return zis; To: //ZipEntryInputStream zis = new ZipEntryInputStream(this, is); //return zis; return is; That is, don't use ZipEntryInputStream, let any class/method invoking openStream to close zipFile's inputStream immediatelly. ZipFile will be in open status, but all steams will be closed well. This makes the process size down to same as JBoss 4's. I tried going through first 3 pages of site, no problems. May need QA team to test more. Btw, I tried updating VFS to 2.1.3.SP1/2.2.0.M4/3.0.0.CR5, first two have same size issue, third one couldn't start. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

6
31
0 / 0

[JBoss JIRA] Created: (JBWEB-168) Limit JspRuntimeContext jsps Map retention

by Mike Millson (JIRA)

Limit JspRuntimeContext jsps Map retention ------------------------------------------ Key: JBWEB-168 URL: https://jira.jboss.org/jira/browse/JBWEB-168 Project: JBoss Web Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Core Affects Versions: JBossWeb-3.0.0.Beta1, JBossWeb-2.1.7.GA, JBossWeb-2.0.0.GA_CP10 Reporter: Mike Millson Assignee: Remy Maucherat Applications with a large number of JSP pages or very large JSP page sizes can lead to retention in the JspRuntimeContext jsps Map. Backport the following Tomcat 7 functionality to limit retention: https://issues.apache.org/bugzilla/show_bug.cgi?id=48358 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

2
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1462) Message expiration is not correctly managed

by Ivan (JIRA)

Message expiration is not correctly managed ------------------------------------------- Key: JBMESSAGING-1462 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1462 Project: JBoss Messaging Issue Type: Bug Components: Messaging Core Affects Versions: 1.4.1.GA Environment: JBAS 5.0GA, JBM 1.4.1GA, persistence on Oracle 10i Reporter: Ivan Assignee: Tim Fox 1) A topic is created 2) A durable subscriber is created fro the topic 3) A message is sent on the topic 4) The durable subscriber pulls the message from the topic ( receive() ) but don't ack 5) The durable subscriber is closed, subscriber session.unsuscribe(name) is called but an exception is thrown and then the subsciber session is closed. As result of this a message, expired, with DELIVERY_COUNT = 1 will remain on the database forever. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

4
20
0 / 0

[JBoss JIRA] Created: (JBRULES-1287) Use of reserved word as bound variable in a pattern results as NPE

by Justin Wick (JIRA)

Use of reserved word as bound variable in a pattern results as NPE ------------------------------------------------------------------ Key: JBRULES-1287 URL: http://jira.jboss.com/jira/browse/JBRULES-1287 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder, Eclipse IDE Affects Versions: 4.0.2 Environment: Eclipse 3.2, Windows XP Reporter: Justin Wick Assigned To: Mark Proctor example: rule "This generates an NPE" when result : ReservedWordNPEFact(data < 15) then result.setData(new Integer(1)); end At least in the eclipse IDE, this generates an NPE. Change result to something like: rule "This generates an NPE" when f: ReservedWordNPEFact(data < 15) then f.setData(new Integer(1)); end and it goes away. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

5
11
0 / 0

[JBoss JIRA] Created: (JBRULES-552) Outline problems in DRL editor

by Dirk Bergstrom (JIRA)

Outline problems in DRL editor ------------------------------ Key: JBRULES-552 URL: http://jira.jboss.com/jira/browse/JBRULES-552 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.0.4 Reporter: Dirk Bergstrom Assigned To: Mark Proctor Priority: Minor Two (possibly related) problems with the outline view in the DRL editor: *) Rules that are commented out via a multi-line comment (/* ... */) still appear in the outline. *) Clicking on the name of a rule highlights some text near that rule. I assume it's supposed to highight the title of the rule, but it misses. Same thing affects the imports. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

4
5
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2011