[JBoss JIRA] (AS7-1338) Remote JNDI support for AS7
by Justin Bertram (JIRA)
[ https://issues.jboss.org/browse/AS7-1338?page=com.atlassian.jira.plugin.s... ]
Justin Bertram commented on AS7-1338:
-------------------------------------
Radek, I recommend you move your question to the AS7 User Forum. It's much more likely that someone will answer your question there.
> Remote JNDI support for AS7
> ---------------------------
>
> Key: AS7-1338
> URL: https://issues.jboss.org/browse/AS7-1338
> Project: Application Server 7
> Issue Type: Task
> Components: Naming
> Reporter: Richard Opalka
> Assignee: John Bailey
> Priority: Critical
> Labels: eap6_prd_req
> Fix For: 7.1.0.Final
>
>
> Add support for remote JNDI after all. It was agreed that:
> * Remote JNDI would run over Remoting
> * Remote JNDI for EJB is strictly a legacy access protocol, deprecated in favor of "ejb:"
> * The Remote JNDI service would proxy to a specific Context of the server JNDI tree - maybe "java:jboss/shared", maybe something else
> * Server-side services would opt-in to Remote JNDI; initially we'd only support:
> ** Remote EJB interfaces
> ** HornetQ connection factories
> * In the future we may support:
> ** User bindings, so long as they're serializable
> * In the future we will never support:
> ** Proxied DataSources
> ** Proxied JMS invocations
> Initial project tree is at https://github.com/dmlloyd/jboss-remote-jndi for now.
--
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
14 years, 2 months
[JBoss JIRA] (AS7-3716) Suspecting EJB remote client server affinity to be broken
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-3716:
-----------------------------------
Summary: Suspecting EJB remote client server affinity to be broken
Key: AS7-3716
URL: https://issues.jboss.org/browse/AS7-3716
Project: Application Server 7
Issue Type: Bug
Components: Clustering, EJB
Affects Versions: 7.1.0.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Priority: Blocker
Fix For: 7.1.1.Final
I am seeing ejb sessions not found in a cache, looks like the client is just not connecting to the correct (same) node and the session has not yet been replicated.
I have never seen this when using Servlet as invocation method for (local) EJBs, thus I blame the remote client.
{noformat}
09:36:35,460 INFO [org.jboss.as.ejb3] (EJB default - 10) JBAS014101: Failed to find {[-125, -49, -119, -124, 127, 13, 64, -111, -65, -22, 109, -71, -85, -44, 70, 35]} in cache
09:36:35,460 INFO [org.jboss.as.ejb3] (EJB default - 7) JBAS014101: Failed to find {[-82, 118, -38, -43, -10, -125, 71, -61, -65, -31, -2, -47, 58, 55, -81, -22]} in cache
09:36:35,465 INFO [org.jboss.as.ejb3] (EJB default - 1) JBAS014101: Failed to find {[-126, -109, 43, 94, -99, -1, 76, -27, -126, 26, 67, 33, 75, 87, 16, -94]} in cache
09:36:35,465 INFO [org.jboss.as.ejb3] (EJB default - 3) JBAS014101: Failed to find {[28, -44, -17, 81, -31, -24, 70, -18, -93, 70, -111, -85, 0, -79, -122, -125]} in cache
09:36:35,465 INFO [org.jboss.as.ejb3] (EJB default - 4) JBAS014101: Failed to find {[-47, -107, 24, 16, 82, 48, 75, 18, -103, 18, 57, 82, 107, 76, -111, 63]} in cache
09:36:35,465 INFO [org.jboss.as.ejb3] (EJB default - 8) JBAS014101: Failed to find {[-4, 23, -92, 114, -66, -34, 77, -114, -81, -109, -36, -14, -94, -70, 52, 80]} in cache
09:36:35,465 INFO [org.jboss.as.ejb3] (EJB default - 2) JBAS014101: Failed to find {[93, 56, 102, -118, -112, 34, 74, -102, -90, -83, 71, 59, -109, 52, -24, -74]} in cache
09:36:35,466 INFO [org.jboss.as.ejb3] (EJB default - 5) JBAS014101: Failed to find {[-36, 51, -36, -12, 18, -36, 64, 74, -113, 120, -42, 20, -61, -79, 94, -6]} in cache
09:36:35,466 INFO [org.jboss.as.ejb3] (EJB default - 6) JBAS014101: Failed to find {[9, -4, 114, 124, 24, -62, 68, -53, -102, -75, -98, -65, -8, -116, -107, 22]} in cache
09:36:35,469 INFO [org.jboss.as.ejb3] (EJB default - 9) JBAS014101: Failed to find {[83, -8, 102, -47, -97, 47, 65, 84, -85, -66, -108, -74, -109, -103, 114, 14]} in cache
09:36:35,461 ERROR [org.jboss.ejb3.invocation] (EJB default - 7) JBAS014134: EJB Invocation failed on component RemoteStatefulSBImpl for method public abstract int org.jboss.test.clusterbench.common.ejb.CommonStatefulSB.getSerialAndIncrement(): javax.ejb.EJBException: java.lang.NullPointerException
at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:166) [jboss-as-ejb3-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:230) [jboss-as-ejb3-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:304) [jboss-as-ejb3-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:190) [jboss-as-ejb3-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropogatingInterceptor.processInvocation(EJBRemoteTransactionPropogatingInterceptor.java:80) [jboss-as-ejb3-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [jboss-as-ejb3-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165) [jboss-as-ee-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:300) [jboss-as-ejb3-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$200(MethodInvocationMessageHandler.java:64) [jboss-as-ejb3-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:194) [jboss-as-ejb3-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [rt.jar:1.6.0_30]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_30]
at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_30]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
Caused by: java.lang.NullPointerException
at org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl.getSerialAndIncrement(CommonStatefulSBImpl.java:27) [clusterbench-common.jar:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_30]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_30]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_30]
at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_30]
at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:127) [jboss-as-weld-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:135) [jboss-as-weld-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36) [jboss-as-ee-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36) [jboss-as-ee-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:58)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:156) [jboss-as-ejb3-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:103) [jboss-as-weld-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:70) [jboss-as-ejb3-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:228) [jboss-as-ejb3-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
... 25 more
{noformat}
Possibly related issues:
https://issues.jboss.org/browse/AS7-3215
https://issues.jboss.org/browse/AS7-2886
--
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
14 years, 2 months
[JBoss JIRA] (AS7-3734) HibernateAnnotationScanner keeps references to application's ClassLoader
by Philippe Guinot (JIRA)
Philippe Guinot created AS7-3734:
------------------------------------
Summary: HibernateAnnotationScanner keeps references to application's ClassLoader
Key: AS7-3734
URL: https://issues.jboss.org/browse/AS7-3734
Project: Application Server 7
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 7.1.0.CR1b
Environment: Seam 2.2.2 application using JPA/Hibernate 3
Reporter: Philippe Guinot
Assignee: Scott Marlow
Well, this is a minor issue as the references are kept in WeakHashMaps. Indeed, the HibernateAnnotationScanner contains static weak maps of the Package/Classes of the current application. They are indexed by PersistenceUnitMetadata.
When the application gets undeployed the PersistenceUnitMetadata is no longer referenced, and should be garbage collected. However the value of the WeahHashMap won't be removed until the next expunging is done. As the application has been undeployed, it does not really make sense to keep strong references to the classes or packages. So, using Set<WeakReference<Package>> and Set<WeakReference<Class<?>>> would improve garbage collecting of the application's class loader and make more PermGen easily available.
--
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
14 years, 2 months
[JBoss JIRA] (AS7-3443) Composite operation on slave host freezes
by Dominik Pospisil (JIRA)
Dominik Pospisil created AS7-3443:
-------------------------------------
Summary: Composite operation on slave host freezes
Key: AS7-3443
URL: https://issues.jboss.org/browse/AS7-3443
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Affects Versions: 7.1.0.Final
Environment: testsuite/domain/src/test/resources/domain-configs/domain-standard.xml
testsuite/domain/src/test/resources/host-configs/host-master.xml
testsuite/domain/src/test/resources/host-configs/host-slave.xml
Reporter: Dominik Pospisil
Assignee: Brian Stansberry
The following composite operation on slave server never finishes:
[domain@localhost:9999 system-property] batch
[domain@localhost:9999 system-property #] /host=slave/system-property=test:add(value="test")
#1 /host=slave/system-property=test:add(value="test")
[domain@localhost:9999 system-property #] /host=slave/system-property=test:write-attribute(name="value", value="test2")
#2 /host=slave/system-property=test:write-attribute(name="value", value="test2")
[domain@localhost:9999 system-property #] run-batch
The above sequences executes fine on master host. It also executes fine if the steps are executed separatelly.
The issue is also reproducible using management API directly (not CLI).
I am using domain configuration from testsuite/domain module.
--
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
14 years, 2 months
[JBoss JIRA] (AS7-3737) Threads ContextClassLoader leak caused by EJB passivation pool
by Philippe Guinot (JIRA)
Philippe Guinot created AS7-3737:
------------------------------------
Summary: Threads ContextClassLoader leak caused by EJB passivation pool
Key: AS7-3737
URL: https://issues.jboss.org/browse/AS7-3737
Project: Application Server 7
Issue Type: Bug
Components: EJB
Affects Versions: 7.1.0.CR1b
Environment: Seam 2.2.2 application
Reporter: Philippe Guinot
Assignee: jaikiran pai
The EJB passivation pool, created at startup, is actually activated only at first use, when an EJB gets passivated. This cause the pool's thread keeping in its context a reference to the context class loader. When the passivation is called, the context class loader is the application class loader.
This actually cause the server keeping a thread which still refers to an application's class loader, even when the application is undeployed.
To avoid such a leak, I changed a few things in org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl
a) In the constructor PassivatingBackingCacheImpl(StatefulObjectFactory<V>, BackingCacheEntryFactory<K, V, E>, ReplicationPassivationManager<K, E>, BackingCacheEntryStore<K, V, E>, ThreadFactory, ScheduledExecutorService), after
{code} this.executor = executor;{code}
I added:{code}
if (this.executor != null) {
this.executor.execute(new Runnable(){
public void run()
{
}});
}{code}
b) In the methodstart(), after
{code} this.executor = Executors.newScheduledThreadPool(1, this.threadFactory);{code}
I added: {code}
if (this.executor != null) {
this.executor.execute(new Runnable(){
public void run()
{
}});
}{code}
This only works because the pools contains only 1 thread.
In addition to this, it seems that the references to the EJB is sometimes not cleaned at undeploy. To do so, I had to change in the stop method:
{code}
if (this.threadFactory != null) {
this.executor.shutdownNow();
}
{code}
to
{code}
if (this.executor != null) {
this.executor.shutdownNow();
}
{code}
Looks like a bug, but I'm not really sure. Anyway, this cleaned the reference to the EJB in the current pool task.
--
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
14 years, 2 months
[JBoss JIRA] (AS7-3725) adjusted JAXWS webservice with webservices.xml descriptor complains about non-existence of jaxrpc-mapping-file element
by Peter Skopek (JIRA)
Peter Skopek created AS7-3725:
---------------------------------
Summary: adjusted JAXWS webservice with webservices.xml descriptor complains about non-existence of jaxrpc-mapping-file element
Key: AS7-3725
URL: https://issues.jboss.org/browse/AS7-3725
Project: Application Server 7
Issue Type: Bug
Components: Web Services
Affects Versions: 7.1.0.Final
Reporter: Peter Skopek
Assignee: Alessio Soldano
When I try to adjust JAXWS webservice with webservices.xml descriptor complains about non-existence of jaxrpc-mapping-file element.
{noformat}
<?xml version="1.0" encoding="UTF-8"?>
<webservices xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/javaee_web_services_1_3.xsd"
version="1.3">
<webservice-description>
<webservice-description-name>
PicketLinkSTS
</webservice-description-name>
<wsdl-file>
WEB-INF/wsdl/PicketLinkSTS.wsdl
</wsdl-file>
<port-component>
<port-component-name>PicketLinkSTSPort</port-component-name>
<wsdl-port xmlns:tns="urn:picketlink:identity-federation:sts">PicketLinkSTSPort</wsdl-port>
<!-- TODO: we don't have interface yet
<service-endpoint-interface>endpoint.WeatherService</service-endpoint-interface>
-->
<service-impl-bean>
<servlet-link>PicketLinkSTS</servlet-link>
</service-impl-bean>
</port-component>
</webservice-description>
</webservices>
{noformat}
Exception:
{noformat}
10:47:32,523 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC00001: Failed to start service jboss.deployment.unit."picketlink-sts.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."picketlink-sts.war".INSTALL: Failed to process phase INSTALL of deployment "picketlink-sts.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
Caused by: org.jboss.ws.WSException: jaxrpc-mapping-file not configured from webservices.xml
at org.jboss.ws.metadata.builder.jaxrpc.JAXRPCServerMetaDataBuilder.buildMetaData(JAXRPCServerMetaDataBuilder.java:107)
at org.jboss.wsf.stack.jbws.UnifiedMetaDataDeploymentAspect.start(UnifiedMetaDataDeploymentAspect.java:74)
at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:81)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
... 5 more
{noformat}
--
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
14 years, 2 months
[JBoss JIRA] Created: (JBRULES-3217) Memory leak in stateless session when using CommandFactory.newInsertElements()
by Mario Fusco (JIRA)
Memory leak in stateless session when using CommandFactory.newInsertElements()
------------------------------------------------------------------------------
Key: JBRULES-3217
URL: https://issues.jboss.org/browse/JBRULES-3217
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Mario Fusco
Assignee: Mario Fusco
Priority: Critical
Description of problem:
There is a memory leak when calling an execute method on
StatelessKnowledgeSession with list of Commands(facts). See the reproducer.
According to heap dump, the
org.drools.command.runtime.rule.InsertElementsCommand is holding references to
facts even after the execute() method is finished.
This is a regression from 5.1.0 GA.
Version-Release number of selected component (if applicable):
BRMS 5.2.0 ER3
How reproducible:
Always
Steps to Reproduce:
1. Run the attached reproducer with ER3 binaries on classpath.
2. Look at stdout to see the raising heap used memory.
Actual results:
Heap used memory is raising.
Expected results:
Heap used memory is not raising. All unused object are collected.
Additional info:
When jBPM jars are not included in classpath, leak is away and memory usage in
not raising.
Memory leak does not occur when StatefulKnowledgeSession is used.
Reported in bugzilla as: https://bugzilla.redhat.com/show_bug.cgi?id=734367
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months