[JBoss JIRA] Created: (AS7-1547) Problem starting jboss 7 with Java Service Wrapper
by andrei povodyrev (JIRA)
Problem starting jboss 7 with Java Service Wrapper
--------------------------------------------------
Key: AS7-1547
URL: https://issues.jboss.org/browse/AS7-1547
Project: Application Server 7
Issue Type: Bug
Components: Logging
Affects Versions: 7.0.0.Final
Environment: Red Hat, Windows 7
Reporter: andrei povodyrev
Assignee: David Lloyd
Fix For: Open To Community
Problem starting jboss 7 with Java Service Wrapper
We tried to upgrade Java Service Wrapper (JSW) configuration from Jboss 5 to Jboss 7.
Jboss fails to start with these messages
WARNING: Failed to load the specified logmodule org.jboss.logmanager:main
followed by IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
Software:
Jboss-as-7.0.0-Final
wrapper-windows-x86-64-3.5.10-st (Java Service Wrapper win 64 distribution)
Issue:
org.jboss.modules.Main generates the warning as LogManager is already initialized to java.util.logging.LogManager by the Wrapper.
With jboss 7 org.jboss.logmanager.LogManager is required. Per LogManager design only one instance may exist in jvm.
jboss 7 assume that it is the first in line to initialize java.util.logger.LogManager.
Wrapper is the one who inits LogManager first (thus triggering primordial
configuration initialization). Jboss then fails to start since it requiresits own logging implementation.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (JASSIST-163) RuntimeSupport.find2Methods a perf hotspot when proxy's methods are called at higher concurrency
by Nikita Tovstoles (JIRA)
Nikita Tovstoles created JASSIST-163:
----------------------------------------
Summary: RuntimeSupport.find2Methods a perf hotspot when proxy's methods are called at higher concurrency
Key: JASSIST-163
URL: https://issues.jboss.org/browse/JASSIST-163
Project: Javassist
Issue Type: Enhancement
Affects Versions: 3.16.1-GA, 3.15.0-GA
Environment: hibernate-core 3.6.10.Final
Reporter: Nikita Tovstoles
Assignee: Shigeru Chiba
We've been profiling our Hibernate 3.6.10-based app and noticed a perf bottleneck in javassist.util.proxy.RuntimeSupport.find2methods. Unfortunately, this method, which has a synch. block, is being called on
every invocation of every proxied entity method (see javassist.util.proxy.ProxyFactory.makeForwarder(), called indirectly by
ProxyFactory.createClass()).
In our testing, the result is that our service call's latency increases from 33 to 55, 260, 400ms as concurrency increases
1-10-20-30 users on a 4-core CPU. At 20 and 30 users 51% of CPU time is spent contending for a monitor in RuntimeSupport.find2methods:
{code}
synchronized (methods) {
if (methods[index] == null) {
methods[index + 1] = thisMethod == null ? null
: findMethod(self, thisMethod, desc);
methods[index] = findSuperMethod(self, superMethod, desc);
}
}
{code}
Since find2methods merely interrogates class metadata, seems like its return values should be cached (in a ConcurrentMap?) instead repeatedly executing the above synchronized statement.
Full [YourKit profiler|http://yourkit.com] is attached, salient screen shots also attached separately
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (AS7-5150) Stack overflow with @Produces and @Inject in one ManagedBean
by Thomas Diesler (JIRA)
Thomas Diesler created AS7-5150:
-----------------------------------
Summary: Stack overflow with @Produces and @Inject in one ManagedBean
Key: AS7-5150
URL: https://issues.jboss.org/browse/AS7-5150
Project: Application Server 7
Issue Type: Bug
Components: CDI / Weld
Reporter: Thomas Diesler
Assignee: Stuart Douglas
This code
{code}
@ManagedBean
public class SimpleManagedBean {
@Inject List<String> providers;
@Produces
public List<String> getPaymentProviders() {
return Arrays.asList("Visa", "Paypal");
}
}
{code}
lead to
{code}
10:36:19,441 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/simple].[SimpleBeanServlet]] (http-/127.0.0.1:8080-1) Allocate exception for servlet SimpleBeanServlet: java.lang.StackOverflowError
at org.jboss.weld.manager.BeanManagerImpl.getId(BeanManagerImpl.java:932) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.manager.BeanManagerImpl.hashCode(BeanManagerImpl.java:855) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at java.util.HashMap.get(HashMap.java:300) [rt.jar:1.6.0_33]
at org.jboss.weld.util.BeansClosure.getClosure(BeansClosure.java:59) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.manager.BeanManagerImpl.getMostSpecializedBean(BeanManagerImpl.java:979) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:626) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:703) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:136) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:686) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:695) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1$1.proceed(ManagedBean.java:161) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1.work(ManagedBean.java:157) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.bean.ManagedBean$FixInjectionPoint.run(ManagedBean.java:131) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.inject(ManagedBean.java:153) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:293) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:68) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:637) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.bean.AbstractReceiverBean.getReceiver(AbstractReceiverBean.java:77) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.bean.AbstractProducerBean$AbstractProducer.produce(AbstractProducerBean.java:317) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:307) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:68) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:637) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:703) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:136) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:686) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:695) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1$1.proceed(ManagedBean.java:161) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1.work(ManagedBean.java:157) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.bean.ManagedBean$FixInjectionPoint.run(ManagedBean.java:131) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.inject(ManagedBean.java:153) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:293) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:68) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:637) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.bean.AbstractReceiverBean.getReceiver(AbstractReceiverBean.java:77) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
at org.jboss.weld.bean.AbstractProducerBean$AbstractProducer.produce(AbstractProducerBean.java:317) [weld-core-1.1.8.Final.jar:2012-04-29 10:45]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] Created: (JBAS-9203) EJBAccessException dont contains my LoginException thrown in a custom LoginModule during login-Method
by Felix Ullrich (JIRA)
EJBAccessException dont contains my LoginException thrown in a custom LoginModule during login-Method
-----------------------------------------------------------------------------------------------------
Key: JBAS-9203
URL: https://issues.jboss.org/browse/JBAS-9203
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: 6.0.0.Final
Reporter: Felix Ullrich
Assignee: Anil Saldhana
This problem was already mentioned here: [http://community.jboss.org/message/114379] A thrown LoginException in a custom LoginModule is not correctly wrapped into the javax.ejb.EJBAccessException on client-side. The cause of EJBAccessException is just not set - its null...
The RemoteClient-Code looks like this
try {
ejb.someMethod();
} catch (final EJBAccessException e) {
e.printStackTrace();
throw e.getCause();
}
and the Stacktrace:
javax.ejb.EJBAccessException: Invalid User
at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:161)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.core.context.CurrentInvocationContextInterceptor.invoke(CurrentInvocationContextInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.interceptor.EJB3TCCLInterceptor.invoke(EJB3TCCLInterceptor.java:86)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.stateful.StatefulContainer.dynamicInvoke(StatefulContainer.java:603)
at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:898)
at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:791)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:744)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:548)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:234)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:216)
at org.jboss.remoting.Client.invoke(Client.java:1961)
at org.jboss.remoting.Client.invoke(Client.java:804)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:77)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.async.impl.interceptor.AsynchronousClientInterceptor.invoke(AsynchronousClientInterceptor.java:143)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
at $Proxy8.invoke(Unknown Source)
at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:185)
at $Proxy7.findAll(Unknown Source)
at RemoteClient.main(RemoteClient.java:22)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:77)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.async.impl.interceptor.AsynchronousClientInterceptor.invoke(AsynchronousClientInterceptor.java:143)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
at $Proxy8.invoke(Unknown Source)
at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:185)
at $Proxy7.findAll(Unknown Source)
at RemoteClient.main(RemoteClient.java:22)
Exception in thread "main" java.lang.NullPointerException
at RemoteClient.main(RemoteClient.java:25)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] (JBRULES-3283) Concurrency issue: Invalid bytecode generated by KnowledgeBuilder.add()
by Thomas Kruse (Created) (JIRA)
Concurrency issue: Invalid bytecode generated by KnowledgeBuilder.add()
-----------------------------------------------------------------------
Key: JBRULES-3283
URL: https://issues.jboss.org/browse/JBRULES-3283
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler (expert)
Affects Versions: 5.3.0.Final, 5.3.0.CR1
Environment: Oracle Java 6, Oracle Java 7, Linux, MacOS
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)
Reporter: Thomas Kruse
Assignee: Mark Proctor
Priority: Minor
Since Drools 5.3.0.CR1 concurrent creation of different knowledgebases from filesystem DRL rule definition leads to illegal bytecode.
Reproduceable with Janino and eclipse compiler.
I have a maven based test project which executes the unit tests in parallel, this is the result:
{code}
runFirst(de.trion.drools53.TwoTest): -1
runFirst(de.trion.drools53.FourTest): (class: de/trion/drools53/Rule_When_a_user_is_young__print_his_name_DefaultConsequenceInvoker, method: equals signature: (Ljava/lang/Object;)Z) Expecting to find integer on stack
runSecond(de.trion.drools53.FourTest): (class: de/trion/drools53/Rule_When_a_user_is_young__print_his_name_DefaultConsequenceInvoker, method: equals signature: (Ljava/lang/Object;)Z) Expecting to find integer on stack
runFirst(de.trion.drools53.OneTest): (class: de/trion/drools53/Rule_When_a_user_is_young__print_his_name_DefaultConsequenceInvoker, method: equals signature: (Ljava/lang/Object;)Z) Expecting to find integer on stack
runFirst(de.trion.drools53.ThreeTest): (class: de/trion/drools53/Rule_When_a_user_is_young__print_his_name_DefaultConsequenceInvoker, method: equals signature: (Ljava/lang/Object;)Z) Incompatible object argument for function call
runSecond(de.trion.drools53.ThreeTest): (class: de/trion/drools53/Rule_When_there_is_god__the_light_always_shines_DefaultConsequenceInvoker, method: equals signature: (Ljava/lang/Object;)Z) Unable to pop operand off an empty stack
{code}
Workaround: synchronize access
Not affected: Drools 5.3.0.Beta
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month