[JBoss JIRA] (WFLY-5337) NPE when restarting Infinispan transport
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5337?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-5337.
----------------------------
> NPE when restarting Infinispan transport
> ----------------------------------------
>
> Key: WFLY-5337
> URL: https://issues.jboss.org/browse/WFLY-5337
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Beta2
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 10.0.0.CR1
>
>
> This is actually due to a bug in Infinispan. Infinispan's JGroupsTransport inappropriately sets its channel to null during stop(), even if a channel was provided to the constructor.
> {noformat}
> 10:10:34,923 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 71) MSC000001: Failed to start service jboss.infinispan.server.default: org.jboss.msc.service.StartException in service jboss.infinispan.server.default: org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type ChannelTransport
> at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:107)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type ChannelTransport
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:248)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:618)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:580)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:445)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:464)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
> at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:120)
> at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:111)
> at org.wildfly.clustering.infinispan.spi.service.CacheBuilder.start(CacheBuilder.java:80)
> at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:102)
> ... 4 more
> Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type ChannelTransport
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:226)
> ... 13 more
> Caused by: java.lang.NullPointerException
> at org.jboss.as.clustering.infinispan.ChannelTransport.initChannel(ChannelTransport.java:84)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:350)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> ... 18 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-5231) [Migration operation] [Web to Undertow] Web - access-log and its directory attributes are not migrated
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5231?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-5231.
----------------------------
> [Migration operation] [Web to Undertow] Web - access-log and its directory attributes are not migrated
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5231
> URL: https://issues.jboss.org/browse/WFLY-5231
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Beta2
> Reporter: Radim Hatlapatka
> Assignee: Stuart Douglas
> Priority: Critical
> Fix For: 10.0.0.CR1
>
>
> When migrating access-log via {{:migrate}} and access-log contains directory definition, the properties {{relative-to}} and {{path}} are not migrated.
> Web subsystem snippet:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default" native="false">
> <virtual-server name="default" enable-welcome-root="true">
> <alias name="localhost"/>
> <alias name="example.com"/>
> <access-log resolve-hosts="true" prefix="test" rotate="false">
> <directory relative-to="jboss.server.log.dir" path="testvs/vs"/>
> </access-log>
> </virtual-server>
> </subsystem>
> {code}
> access log part expected to be migrated as
> {code:xml}
> <access-log rotate="false" prefix="test" directory="testvs/vs" relative-to="jboss.server.log.dir" />
> {code}
> instead it is migrated without the {{directory}} and {{relative-to}} attributes:
> <access-log rotate="false" prefix="test"/>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-4569) EntityBean instances are leaked from pool on certain exceptions
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4569?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-4569.
----------------------------
> EntityBean instances are leaked from pool on certain exceptions
> ---------------------------------------------------------------
>
> Key: WFLY-4569
> URL: https://issues.jboss.org/browse/WFLY-4569
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.2.0.Final, 9.0.0.Beta2, 9.0.0.CR1
> Reporter: Alexey Makhmutov
> Assignee: Alexey Makhmutov
> Fix For: 9.0.0.CR2, 10.0.0.Alpha1
>
>
> Entity beans instances may not be returned to the pool after certain exceptions, which may lead to pool exhaustion.
> Currently, following two cases are discovered:
> # If any exception is thrown from ejbCreate method (e.g. duplicate record was found in the database), then bean instance won’t be returned to the pool, as there are no try-finally statements around call to ejbCreate in EntityBeanEjbCreateMethodInterceptor/EntityBeanRemoteViewInstanceFactory classes for this call.
> # If runtime exception (such as EJBException) is thrown from business method, then instance won’t be returned to the pool, as it will be marked as discarded by EntityBeanAssociatingInterceptor and both ReferenceCountingEntityCache/TransactionLocalEntityCache cache implementations just ignores discarded instance on release call.
> These problems actually make impossible using of pooled instances with Entity beans, as number of used beans from pool will be steadily increasing in production until pool is exhausted and clients start getting ‘Failed to acquire permit’ exceptions.
> Here is the set of integration tests, which examines the described behavior: https://github.com/Lerm/jboss-as/commit/f3eadd96d84dabc0a8b9c6c866ccfd5fe...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months