[JBoss JIRA] Created: (JBAS-8938) Separate $JAVA_OPTS for ProcessController and HostController
by Brian Stansberry (JIRA)
Separate $JAVA_OPTS for ProcessController and HostController
------------------------------------------------------------
Key: JBAS-8938
URL: https://issues.jboss.org/browse/JBAS-8938
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
The way domain.sh and domain.conf work now, whatever value gets assigned to $JAVA_OPTS gets passed to java, so affects the vm used for the ProcessController, and then gets passed through as a param to the PC which uses it for creating the HostController process.
We should have a separate variable for the PC, or perhaps use $JAVA_OPTS for neither and have 2 new variables. Settings for the PC are unlikely to be optimum for the HC, and using the same var makes it harder to set of debugging (e.g. both the PC and HC process will try and use the same port for remote socket debugging.)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 7 months
[JBoss JIRA] Created: (EJBTHREE-2256) ExtendedEntityManager injected into Stateless Session Bean
by gunter zeilinger (JIRA)
ExtendedEntityManager injected into Stateless Session Bean
----------------------------------------------------------
Key: EJBTHREE-2256
URL: https://issues.jboss.org/browse/EJBTHREE-2256
Project: EJB 3.0
Issue Type: Bug
Components: injection
Environment: Running Arquillian 1.0.0.Alpha5 JUnit testcase with jbossas-remote-6 in jboss-6.0.0.Final
Reporter: gunter zeilinger
Injecting a Stateless and a Stateful Session Bean - the later with an Extended Presentation Context - into a managed object:
{code}
@RunWith(Arquillian.class)
public class MyTest {
@EJB
private MySFSB sfsb;
@EJB
private MySLSB slsb;
:
{code}
may cause that the {{ExtendedEntityManager}} from the SFSB get also injected into the SLSB, which results in:
{noformat}
java.lang.NullPointerException at org.jboss.ejb3.entity.ExtendedEntityManager.getPersistenceContext(ExtendedEntityManager.java:76)
at org.jboss.ejb3.entity.ExtendedEntityManager.getEntityManager(ExtendedEntityManager.java:61)
at org.jboss.ejb3.jpa.integration.JPA2EntityManagerDelegator.createNamedQuery(JPA2EntityManagerDelegator.java:44)
at MySLSB.foo(MySLSB.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
at org.jboss.ejb3.interceptors.container.ContainerMethodInvocationWrapper.invokeNext(ContainerMethodInvocationWrapper.java:72)
at org.jboss.ejb3.interceptors.aop.InterceptorSequencer.invoke(InterceptorSequencer.java:76)
at org.jboss.ejb3.interceptors.aop.InterceptorSequencer.aroundInvoke(InterceptorSequencer.java:62)
...
{noformat}
The failure does not occur on each run - sometimes the SLSB get its own {{org.jboss.jpa.tx.TransactionScopedEntityManager}} injected as expected, and the test passes.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 7 months
[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, 7 months
[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, 7 months
[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
14 years, 7 months