July 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (LOGTOOL-6) Remove file sorting before processing translation file

by Kevin Pollet (JIRA)

Remove file sorting before processing translation file ------------------------------------------------------ Key: LOGTOOL-6 URL: https://issues.jboss.org/browse/LOGTOOL-6 Project: Log Tool Issue Type: Enhancement Security Level: Public (Everyone can see) Affects Versions: 1.0.0.Beta1 Reporter: Kevin Pollet Assignee: David Lloyd Fix For: 1.0.0.Beta2 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

3
5
0 / 0

[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

13 years, 3 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

13 years, 3 months

4
5
0 / 0

[JBoss JIRA] Created: (JBAS-9205) Clicking on a subsytem in web console shows a "Could not reveal xxx" message

by jaikiran pai (JIRA)

Clicking on a subsytem in web console shows a "Could not reveal xxx" message ---------------------------------------------------------------------------- Key: JBAS-9205 URL: https://issues.jboss.org/browse/JBAS-9205 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Console Environment: JBoss AS7 upstream (March 31 2011) Reporter: jaikiran pai Assignee: Heiko Braun Attachments: ejb3-subsystem.png Logging into AS7 web console and clicking on any of the subsystems under the "Subsystem" tree shows a error message like: "Could not reveal: server/ejb3". The server has been started in standalone mode. OS: Ubuntu 10.10 Browser : Firefox 3.6.3 JDK: Sun Java 1.6.0_21 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

2
5
0 / 0

[JBoss JIRA] Created: (AS7-1139) Can't use jboss-admin.sh to add configuration to a subsystem

by Darrin Mison (JIRA)

Can't use jboss-admin.sh to add configuration to a subsystem ------------------------------------------------------------ Key: AS7-1139 URL: https://issues.jboss.org/browse/AS7-1139 Project: Application Server 7 Issue Type: Bug Components: CLI Reporter: Darrin Mison Trying to use the jboss-admin.sh to update configuration on standalone AS7 and think I'm missing either some documentation or I didn't understand it. For this particular example I was trying to disable sub-deployment module isolation as described https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7 but by using the admin CLI instead of hand editing XML. I can "cd" to the /subsystem=ee node fine. I just don't know how to add new configuration. I'm assuming this is possible in the API but not yet exposed in the tool? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-3116) Performance Regression due to mvel ParserContext now set, resulting in CompositeClassLoader loads

by Fabian Lange (JIRA)

Performance Regression due to mvel ParserContext now set, resulting in CompositeClassLoader loads ------------------------------------------------------------------------------------------------- Key: JBRULES-3116 URL: https://issues.jboss.org/browse/JBRULES-3116 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.2.0.Final Reporter: Fabian Lange Assignee: Mark Proctor I observed this issue already with 5.1, but now had time to verify it with 5.2. Initial compilation time has exploded with those versions. I have with the same test cases with 5.2 this: org.drools.util.CompositeClassLoader$CachingLoader.load taking a total of 42 seconds With 5.0 (where this Caching was not yet implemented) I had a total time of less than 5 seconds spend in the ClassLoading. The reason for this took me a while to find, but now I do have it: org.mvel2.compiler.AbstractParser.createPropertyToken is invoking hasImports() and getImport() on the ParseContext if not null. Those in turn are invoking org.mvel2.ParserConfiguration.checkForDynamicImport which invokes org.drools.util.CompositeClassLoader.loadClass This is invoked on my table for expressions like this: "age >= 16" So the org.drools.util.CompositeClassLoader$CachingLoader.load will look for a class called "age" and a class called "16". Because the class not exists null/false are returned from the callchain. However neither the CachingLoader, nor the Map in AbstractParser will cache the negative result. Causing this to happen for each row in my decisiontable. And in 5.0 the whole part of the callgraph is not there. I figured out, that in 5.0 versions, the AbstractParser never had a parse context in createPropertyToken This might be because of the inconsistent usage of protected static ThreadLocal<ParserContext> parserContext; protected ParserContext pCtx; So where does us leave this? A possible easy solution would be to add the "negative" lookups to the CachingLoader. However I would like to have doublechecked if the change in Abstract Parser was intentional and is now working correctly. Thus invoking the checkDynamicImports a lot is correct. Is it really the case that the parser needs to check for each literal this dynamic import thing? it obviously didnt do before. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

4
6
0 / 0

[JBoss JIRA] Created: (JBRULES-3005) decision table building => NPE

by Wolfgang Laun (JIRA)

decision table building => NPE ------------------------------ Key: JBRULES-3005 URL: https://issues.jboss.org/browse/JBRULES-3005 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler (expert) Affects Versions: 5.2.0.M2 Reporter: Wolfgang Laun Assignee: Mark Proctor kBuilder.add( resource, resourceType.DTABLE ); results in a NPE: Exception in thread "main" java.lang.NullPointerException at org.drools.decisiontable.DecisionTableProviderImpl.compileStream(DecisionTableProviderImpl.java:26) at org.drools.decisiontable.DecisionTableProviderImpl.loadFromInputStream(DecisionTableProviderImpl.java:19) at org.drools.compiler.DecisionTableFactory.loadFromInputStream(DecisionTableFactory.java:18) at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:497) at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:28) at rss.drools.setup.Application.setup(Application.java:47) Notice that a simple DecisionTableConfiguration dtConf = KnowledgeBuilderFactory.newDecisionTableConfiguration(); kBuilder.add( resource, resourceType, dtConf ); is not sufficient, the DecisionTableConfiguration still needs a DecisionTableInputType Expected. there is a reasonable default DecisionTableConfiguration with DecisionTableInputType.XLS being set. The simple call worked fine in 5.1. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

3
6
0 / 0

[JBoss JIRA] Created: (JBAS-9329) Restore persistent configuration changes

by Thomas Diesler (JIRA)

Restore persistent configuration changes ----------------------------------------- Key: JBAS-9329 URL: https://issues.jboss.org/browse/JBAS-9329 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Thomas Diesler The ConfigAdminService used the ServerConfigurationPersister in the past. The code is currently commented out -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
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

13 years, 3 months

3
8
0 / 0

[JBoss JIRA] Created: (AS7-1138) Port displayed incorrectly for sockets with port 0

by Brian Stansberry (JIRA)

Port displayed incorrectly for sockets with port 0 -------------------------------------------------- Key: AS7-1138 URL: https://issues.jboss.org/browse/AS7-1138 Project: Application Server 7 Issue Type: Bug Components: Console Affects Versions: 7.0.0.CR1 Reporter: Brian Stansberry The console shows negative port values for the JGroups sockets in the ha-sockets socket binding group. My assumption is this has something to do with them having '0' as their port value. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

2
2
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2011