[JBoss JIRA] (WFLY-6691) Cache container enable statistics can lead to classloader leak
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-6691:
----------------------------------
Summary: Cache container enable statistics can lead to classloader leak
Key: WFLY-6691
URL: https://issues.jboss.org/browse/WFLY-6691
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Fix For: 10.1.0.Final
In standalone.xml, if we enable statistics such as:
{code}
<cache-container name="web" default-cache="repl" module="org.wildfly.clustering.web.infinispan" statistics-enabled="true">
<transport lock-timeout="60000"/>
<replicated-cache name="repl" statistics-enabled="true" mode="ASYNC">
<locking isolation="READ_COMMITTED"/>
<transaction locking="OPTIMISTIC" mode="BATCH"/>
<state-transfer chunk-size="512" timeout="240000"/>
</replicated-cache>
</cache-container>
{code}
The following MBean:
{code}
jboss.infinispan:cluster=web,type=channel
{code}
is getting eventually registered when deploying any application.
When undeploying that application, the MBean is not getting unregistered and thus can leak pretty much anything.
Also, if you try to deploy the very same application right after another MBean will get registered:
{code}
jboss.infinispan2:cluster=web,type=channel
{code}
Note: cache enable-statistics=true doesn't seems to leak anything.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6692) Provide minimalistic profile for Artemis backup configuration
by Miroslav Novak (JIRA)
Miroslav Novak created WFLY-6692:
------------------------------------
Summary: Provide minimalistic profile for Artemis backup configuration
Key: WFLY-6692
URL: https://issues.jboss.org/browse/WFLY-6692
Project: WildFly
Issue Type: Feature Request
Components: JMS
Affects Versions: 10.0.0.Final
Reporter: Miroslav Novak
Assignee: Jeff Mesnil
If Artemis is configured as dedicated backup no deployments like MDB,EJB,Servlets should be deployed to it. It should serve to its purpose which is to wait for Wildfly 10 with Artemis configured as live to fail.
We should provide minimalistic configuration for Wildfly serving purely as Artemis backup server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6678) StackoverflowError ejbclientinvocationcontext
by Jimmy Pannier (JIRA)
[ https://issues.jboss.org/browse/WFLY-6678?page=com.atlassian.jira.plugin.... ]
Jimmy Pannier commented on WFLY-6678:
-------------------------------------
Hi again,
i have other traces with this recursive method but it's another wildfly code.
Note that the implementation of ejb can throws exception that rollback transaction.
@ApplicationException(rollback = true)
public class CloudException extends Exception{...}
2016-06-09 11:52:45,892 ERROR [org.jboss.as.ejb3.invocation] (default task-32) {color:red}WFLYEJB0034{color}: EJB Invocation failed on component PatientProfessionalLinkServiceImpl for method public abstract com.inovelan.cloud.api.directory.model.ws.link.LinkPatientToProfessionalResponse com.inovelan.cloud.api.directory.service.link.IPatientProfessionalEjbService.linkExternalPatientWithProfessional(com.inovelan.cloud.api.directory.model.ws.link.LinkPatientToProfessionalRequest) throws com.inovelan.cloud.common.client.proxy.exception.CloudException: javax.ejb.EJBTransactionRolledbackException: WFLYEJB0457: Unexpected Error
at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:153)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:256)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:634)
at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:261)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:184)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocation(ProxyInterceptor.java:28)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocation(ProxyInterceptor.java:28)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocation(ProxyInterceptor.java:28)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
....
> StackoverflowError ejbclientinvocationcontext
> ---------------------------------------------
>
> Key: WFLY-6678
> URL: https://issues.jboss.org/browse/WFLY-6678
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Environment: wildfly 9.0.1, jdk 1.8
> Reporter: Jimmy Pannier
> Attachments: server.log
>
>
> Sometimes after few days i get an exception
> Here is a stacktrace.
> 2016-06-07 07:38:10,441 ERROR [org.jboss.as.ejb3.invocation] (default task-76) WFLYEJB0034: EJB Invocation failed on component StorageServiceImpl for method public abstract java.util.List com.inovelan.cloud.api.storage.service.dataset.IStorageEjbService.loadData(com.inovelan.cloud.api.storage.model.dto.dataset.LoadDataConfig): javax.ejb.EJBTransactionRolledbackException: WFLYEJB0457: Unexpected Error
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:153)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:256)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> .....
> Caused by: java.lang.StackOverflowError
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6686) JGroups ForkChannel can hold references to Hibernate SessionFactoryImpl which cause memory leak
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6686?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-6686:
-------------------------------
Priority: Blocker (was: Major)
> JGroups ForkChannel can hold references to Hibernate SessionFactoryImpl which cause memory leak
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-6686
> URL: https://issues.jboss.org/browse/WFLY-6686
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Environment: Using WF 10 build #2291 (Jun 6, 2016 3:40:44 PM)
> https://ci.jboss.org/hudson/job/WildFly-latest-master/2291/changes
> Reporter: Mathieu Lachance
> Assignee: Paul Ferraro
> Priority: Blocker
> Fix For: 10.1.0.Final
>
>
> We are using Hibernate second level cache through JPA configured as such:
> {code}
> <properties>
> <property name="hibernate.cache.use_query_cache" value="true"/>
> <property name="hibernate.cache.use_second_level_cache" value="true"/>
> <property name="hibernate.cache.region.factory_class" value="org.jboss.as.jpa.hibernate5.infinispan.SharedInfinispanRegionFactory"/>
> </properties>
> {code}
> After heap dump inspection, it seems that the JGroups ForkChannel identified by "hibernate" can hold a listener that hold the SessionFactoryImpl which then hold the whole application classloader.
> When undeploying the application, this can lead to classloader leak.
> I took an heap dump of such scenario and analysed it using eclipse memory analyzer (MAT) and here is the result:
> {code}
> Class Name | Ref. Objects | Shallow Heap | Ref. Shallow Heap | Retained Heap
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> channel org.jgroups.JChannel @ 0xc0eac6a0 | 1 | 112 | 136 | 448
> '- channel_listeners java.util.concurrent.CopyOnWriteArraySet @ 0xc0ecd260 | 1 | 16 | 136 | 112
> '- al java.util.concurrent.CopyOnWriteArrayList @ 0xc0ecd270 | 1 | 24 | 136 | 96
> '- array java.lang.Object[2] @ 0xc0ecd2b8 | 1 | 24 | 136 | 24
> '- [0] org.jgroups.fork.ForkChannel @ 0xc103d250 | 1 | 120 | 136 | 1 328
> '- channel_listeners java.util.concurrent.CopyOnWriteArraySet @ 0xc103d350 | 1 | 16 | 136 | 968
> '- al java.util.concurrent.CopyOnWriteArrayList @ 0xc103d360 | 1 | 24 | 136 | 952
> '- array java.lang.Object[1] @ 0xc103d3a8 | 1 | 24 | 136 | 880
> '- [0] org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher @ 0xc103d1f0| 1 | 96 | 136 | 856
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> {code}
> To remove that leak I ugily patched JGroups ForkChannel close method as such:
> {code}
> /** Closes the fork-channel, essentially setting its state to CLOSED. Note that - contrary to a regular channel -
> * a closed fork-channel can be connected again: this means re-attaching the fork-channel to the main-channel*/
> @Override
> public void close() {
> ((ForkProtocolStack)prot_stack).remove(fork_channel_id);
> if(state == State.CLOSED)
> return;
> disconnect(); // leave group if connected
> prot_stack.destroy();
> state=State.CLOSED;
> notifyChannelClosed(this);
> this.clearChannelListeners(); // <-- this is the line I added
> }
> {code}
> With that change in place, the memory leak is gone. I highly doubt though this is an acceptable fix. Though it does confirm my theory.
> I doubt that JGroups is really the culprit -- I'm more in the thinking that the "thing managing" JGroups is the culprit.
> Since I'm not an expert around that field I've opened the issue against the Wildfly project. Feel free to move it to the proper project.
> If you need any other informations let me know.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6662) Statement.cancel() is not invoked until the statement is completed
by Frank Wippermüller (JIRA)
[ https://issues.jboss.org/browse/WFLY-6662?page=com.atlassian.jira.plugin.... ]
Frank Wippermüller commented on WFLY-6662:
------------------------------------------
Same behaviour/bug with latest version ironjacamar-jdbc-1.3.4. Unfortunately, *this bug is preventing canceling of all queries*, i.e. not only canceling of custom {{PreparedStatements}}, but *any Hibernate queries* as well, as Hibernate is using {{WrappedStatement.cancel}}, too!
Please remove locking in {{WrappedStatement.cancel}} in a future release.
Thank you,
Frank
> Statement.cancel() is not invoked until the statement is completed
> ------------------------------------------------------------------
>
> Key: WFLY-6662
> URL: https://issues.jboss.org/browse/WFLY-6662
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 9.0.2.Final
> Reporter: lorenzo benvenuti
> Assignee: Jesper Pedersen
>
> Hi,
> in our application we are using the {{Statement.cancel()}} method to stop long-running queries; in Wildfly 9.0.2 this is not working because the {{cancel()}} method is synchronized using a lock which is not released until the query is executed. In {{WrappedStatement}}:
> {code:java}
> public void cancel() throws SQLException
> {
> if (doLocking)
> lock();
> try
> {
> /* ... */
> {code}
> It seems this behaviour has changed from version 1.2.5.Final of ironjacamar-jdbc; in version 1.2.4.Final {{WrappedStatement.cancel}} doesn't try to obtain the lock.
> Probably I'm missing something, but to me it's strange that in order to cancel a statement you have to wait for its completion.
> Thank you,
> lorenzo
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (JGRP-2078) NPE in Ipv6 Solaris 10 test
by Bogdan Sikora (JIRA)
[ https://issues.jboss.org/browse/JGRP-2078?page=com.atlassian.jira.plugin.... ]
Bogdan Sikora commented on JGRP-2078:
-------------------------------------
I've noticed it only once, so probably not without huge digging into what exactly happened
> NPE in Ipv6 Solaris 10 test
> ---------------------------
>
> Key: JGRP-2078
> URL: https://issues.jboss.org/browse/JGRP-2078
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.8
> Reporter: Bogdan Sikora
> Assignee: Bela Ban
>
> {noformat}
> 2016-06-08 05:49:40,139 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000079: Channel ejb local address is jboss-eap-7.0, physical addresses are [2620:52:0:105f:0:0:ffff:51%2:55200]
> 2016-06-08 05:49:40,139 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000079: Channel server local address is jboss-eap-7.0, physical addresses are [2620:52:0:105f:0:0:ffff:51%2:55200]
> 2016-06-08 05:49:40,139 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000079: Channel hibernate local address is jboss-eap-7.0, physical addresses are [2620:52:0:105f:0:0:ffff:51%2:55200]
> 2016-06-08 05:49:40,139 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000079: Channel web local address is jboss-eap-7.0, physical addresses are [2620:52:0:105f:0:0:ffff:51%2:55200]
> {noformat}
> {noformat}
> 2016-06-08 05:50:01,589 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 69) WFLYCLINF0002: Started clusterbench.war cache from web container
> 2016-06-08 05:50:01,625 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 64) WFLYCLINF0002: Started routing cache from web container
> 2016-06-08 05:50:02,894 ERROR [org.jgroups.protocols.UNICAST3] (thread-2,ee,jboss-eap-7.0) JGRP000043: jboss-eap-7.0: failed handling event: java.lang.NullPointerException
> 2016-06-08 05:50:03,379 ERROR [org.jgroups.protocols.UNICAST3] (thread-2,ee,jboss-eap-7.0) JGRP000043: jboss-eap-7.0: failed handling event: java.lang.NullPointerException
> 2016-06-08 05:50:03,878 ERROR [org.jgroups.protocols.UNICAST3] (thread-1,ee,jboss-eap-7.0) JGRP000043: jboss-eap-7.0: failed handling event: java.lang.NullPointerException
> ...
> {noformat}
> https://paste.fedoraproject.org/376166/65389534/
> Config
> https://paste.fedoraproject.org/376150/
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6690) Read-resource(include-runtime=true) fais on jms-bridge in domain mode
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-6690:
---------------------------------
Summary: Read-resource(include-runtime=true) fais on jms-bridge in domain mode
Key: WFLY-6690
URL: https://issues.jboss.org/browse/WFLY-6690
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 10.0.0.Final
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
/profile=full/subsystem=messaging-activemq/jms-bridge=bridge-mane-3:read-resource(include-runtime=true)
{
"outcome" => "failed",
"rolled-back" => true
}
The server log
[Host Controller] 15:30:49,150 ERROR
[org.jboss.as.controller.management-operation]
(management-handler-thread - 9) WFLYCTL0013: Operation
("read-attribute") failed - address: ([
[Host Controller] ("profile" => "full"),
[Host Controller] ("subsystem" => "messaging-activemq"),
[Host Controller] ("jms-bridge" => "bridge-mane-3")
[Host Controller] ]) - failure description: "WFLYCTL0216: Management resource '[
[Host Controller] (\"profile\" => \"full\"),
[Host Controller] (\"subsystem\" => \"messaging-activemq\"),
[Host Controller] (\"jms-bridge\" => \"bridge-mane-3\")
[Host Controller] ]' not found"
Remove the include-runtime=true, it works.
The issue lies with the "paused" and "started" runtime attributes whose read handler throws an exception if the bridge is not available in the runtime (that is the case in the profile).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months