December 2017 - jboss-jira - Jboss List Archives

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (WFLY-5089) Upgrade Narayana to 5.2.2.Final

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-5089?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-5089. ---------------------------- > Upgrade Narayana to 5.2.2.Final > ------------------------------- > > Key: WFLY-5089 > URL: https://issues.jboss.org/browse/WFLY-5089 > Project: WildFly > Issue Type: Component Upgrade > Components: Transactions > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 10.0.0.Beta2 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3171) Increase default state transfer timeout

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-3171?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-3171. ---------------------------- > Increase default state transfer timeout > --------------------------------------- > > Key: WFLY-3171 > URL: https://issues.jboss.org/browse/WFLY-3171 > Project: WildFly > Issue Type: Enhancement > Components: Clustering > Affects Versions: 8.0.0.Final > Reporter: Paul Ferraro > Assignee: Radoslav Husar > Fix For: 10.0.0.CR1 > > > The current state transfer timeout is 1 minute. Now that Infinispan uses non-blocking state transfer, we should bump this to 4 minutes, in line with Infinispan's defaults. > Don't forget to include transformers for old model versions. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5329) Add support for an automatic configured strict-max-pool and make it the default for SLSB and MDBs

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-5329?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-5329. ---------------------------- > Add support for an automatic configured strict-max-pool and make it the default for SLSB and MDBs > ------------------------------------------------------------------------------------------------- > > Key: WFLY-5329 > URL: https://issues.jboss.org/browse/WFLY-5329 > Project: WildFly > Issue Type: Feature Request > Reporter: Jason Greene > Assignee: Jason Greene > Fix For: 10.0.0.CR1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4739) Add option to disable websockets on a per deployment basis

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4739?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4739. ---------------------------- > Add option to disable websockets on a per deployment basis > ---------------------------------------------------------- > > Key: WFLY-4739 > URL: https://issues.jboss.org/browse/WFLY-4739 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 10.0.0.Alpha4 > > > This will use the existing jboss-web.xml flag -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4819) Upgrade Apache CXF from 3.0.5 to 3.1.2

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4819?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4819. ---------------------------- > Upgrade Apache CXF from 3.0.5 to 3.1.2 > -------------------------------------- > > Key: WFLY-4819 > URL: https://issues.jboss.org/browse/WFLY-4819 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Services > Reporter: Tomas Hofman > Assignee: Alessio Soldano > Fix For: 10.0.0.Beta1 > > > Upgrade to Apache CXF 3.1.2 when available. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4585) Provide JMS forward compatibility

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4585?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4585. ---------------------------- > Provide JMS forward compatibility > --------------------------------- > > Key: WFLY-4585 > URL: https://issues.jboss.org/browse/WFLY-4585 > Project: WildFly > Issue Type: Sub-task > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 10.0.0.Alpha5 > > > Older JMS clients (from WildFly 8/9) with HornetQ client libraries must be able to communicate with WildFly 10 and ActiveMQ Artemis. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4429) Refactor JCA subsystems

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4429?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4429. ---------------------------- > Refactor JCA subsystems > ----------------------- > > Key: WFLY-4429 > URL: https://issues.jboss.org/browse/WFLY-4429 > Project: WildFly > Issue Type: Task > Components: JCA > Reporter: Jesper Pedersen > Assignee: Stefano Maestri > Priority: Critical > Fix For: 10.0.0.Alpha4 > > > Make use of PASSIVE services in :jca:, :datasources: and :resource-adapters: -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[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

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2017