June 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-10280) Can't enable stateful EJB passivation when EJB remote service is removed

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-10280?page=com.atlassian.jira.plugin... ] Bartosz Baranowski edited comment on WFLY-10280 at 6/21/18 12:52 AM: --------------------------------------------------------------------- -What is puzzling is that if you enable passivation after remove of remote, everything is fine. Thus, dialing back to minor, since workaround exist.- was (Author: baranowb): What is puzzling is that if you enable passivation after remove of remote, everything is fine. Thus, dialing back to minor, since workaround exist. > Can't enable stateful EJB passivation when EJB remote service is removed > ------------------------------------------------------------------------ > > Key: WFLY-10280 > URL: https://issues.jboss.org/browse/WFLY-10280 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 12.0.0.Final > Reporter: Ladislav Thon > Assignee: Bartosz Baranowski > Attachments: tinyEjbPassivation.war > > > In WildFly Swarm, we don't have EJB remoting enabled by default, but would still like to be able to use stateful EJB passivation. We can't because of this bug. > What I do here is change the default SFSB cache to {{passivating}}, thereby enabling SFSB passivation, and also remove the {{remote}} service (which is what we do in WildFly Swarm by default). > When reloading the server to normal mode, deployment fails with a lot of errors, the main culprit seems to be the EJB client mappings registry: > {code} > 17:16:37,216 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache] > service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation, service jboss.deployment.unit."tinyEjbPassivation.war".WeldEndInitService] > service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START] > service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService] > service org.wildfly.clustering.cache.registry.ejb.client-mappings (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager] > service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings (missing) dependents: [service org.wildfly.clustering.cache.registry.ejb.client-mappings] > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10280) Can't enable stateful EJB passivation when EJB remote service is removed

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-10280?page=com.atlassian.jira.plugin... ] Bartosz Baranowski edited comment on WFLY-10280 at 6/21/18 12:48 AM: --------------------------------------------------------------------- Possibly it is just silently ignored. Thing is that during configuration of clustering, some config providers ignore cache name ( passivation ) and default to "client-mappings" mappings for instance. -btw, it does not explode with workaround I call it a good workaround.- It seems it does not work at all. was (Author: baranowb): Possibly it is just silently ignored. Thing is that during configuration of clustering, some config providers ignore cache name ( passivation ) and default to "client-mappings" mappings for instance. btw, it does not explode with workaround I call it a good workaround. > Can't enable stateful EJB passivation when EJB remote service is removed > ------------------------------------------------------------------------ > > Key: WFLY-10280 > URL: https://issues.jboss.org/browse/WFLY-10280 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 12.0.0.Final > Reporter: Ladislav Thon > Assignee: Bartosz Baranowski > Attachments: tinyEjbPassivation.war > > > In WildFly Swarm, we don't have EJB remoting enabled by default, but would still like to be able to use stateful EJB passivation. We can't because of this bug. > What I do here is change the default SFSB cache to {{passivating}}, thereby enabling SFSB passivation, and also remove the {{remote}} service (which is what we do in WildFly Swarm by default). > When reloading the server to normal mode, deployment fails with a lot of errors, the main culprit seems to be the EJB client mappings registry: > {code} > 17:16:37,216 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache] > service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation, service jboss.deployment.unit."tinyEjbPassivation.war".WeldEndInitService] > service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START] > service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService] > service org.wildfly.clustering.cache.registry.ejb.client-mappings (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager] > service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings (missing) dependents: [service org.wildfly.clustering.cache.registry.ejb.client-mappings] > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBREM-1328) LeasePinger should not use a static Timer

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1328?page=com.atlassian.jira.plugin... ] Ron Sigal resolved JBREM-1328. ------------------------------ Resolution: Done > LeasePinger should not use a static Timer > ----------------------------------------- > > Key: JBREM-1328 > URL: https://issues.jboss.org/browse/JBREM-1328 > Project: JBoss Remoting > Issue Type: Bug > Affects Versions: 2.5.4.SP5 > Reporter: Ron Sigal > Assignee: Ron Sigal > Fix For: 2.5.4.SP6 > > > org.jboss.remoting.LeasePinger currently uses a static Timer. If one LeasePinger gets hung up waiting for a response, it can prevent another LeasePinger from sending a PING, leading to a broken Lease on the server. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBREM-1329) Reused ConnectionValidator can hold a reference to a disconnected Client

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1329?page=com.atlassian.jira.plugin... ] Ron Sigal resolved JBREM-1329. ------------------------------ Resolution: Done > Reused ConnectionValidator can hold a reference to a disconnected Client > ------------------------------------------------------------------------ > > Key: JBREM-1329 > URL: https://issues.jboss.org/browse/JBREM-1329 > Project: JBoss Remoting > Issue Type: Bug > Affects Versions: 2.5.4.SP5 > Reporter: Ron Sigal > Assignee: Ron Sigal > Fix For: 2.5.4.SP6 > > > Instances of org.jboss.remoting.ConnectionValidator hold a reference to an org.jboss.remoting.Client, from which it obtains the value of clientLeasePeriod. If the ConnectionValidator is being reused, and the Client it points to has been disconnected, it gets a value of -1 and it doesn't tie pinging to a Lease. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBREM-1330) Lease$LeaseTimerTask has a race condition

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1330?page=com.atlassian.jira.plugin... ] Ron Sigal resolved JBREM-1330. ------------------------------ Resolution: Done > Lease$LeaseTimerTask has a race condition > ----------------------------------------- > > Key: JBREM-1330 > URL: https://issues.jboss.org/browse/JBREM-1330 > Project: JBoss Remoting > Issue Type: Bug > Affects Versions: 2.5.4.SP5 > Reporter: Ron Sigal > Assignee: Ron Sigal > Fix For: 2.5.4.SP6 > > > org.jboss.remoting.Lease$LeasePinger and org.jboss.remoting.ServerInvoker both access the map of existing Leases. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBREM-1326) Socket read timeout is not set on Control Thread/Socket

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1326?page=com.atlassian.jira.plugin... ] Ron Sigal closed JBREM-1326. ---------------------------- Resolution: Out of Date > Socket read timeout is not set on Control Thread/Socket > ------------------------------------------------------- > > Key: JBREM-1326 > URL: https://issues.jboss.org/browse/JBREM-1326 > Project: JBoss Remoting > Issue Type: Bug > Environment: JBoss EAP 5 > Reporter: Doug Grove > Assignee: Ron Sigal > > It is possible for an unhandled exception to be thrown from the EJB container that causes orphaned control threads to accumulate: > "control: Socket[addr=127.0.0.1,port=45892,localport=51040]" daemon prio=3 tid=0x056c2800 nid=0x2002 runnable [0x5ba4f000] > java.lang.Thread.State: RUNNABLE > java.net.SocketInputStream.socketRead0(Native Method) > java.net.SocketInputStream.read(SocketInputStream.java:129) > java.net.SocketInputStream.read(SocketInputStream.java:182) > java.io.FilterInputStream.read(FilterInputStream.java:66) > The socket read blocks indefinitely as there is no timeout. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBREM-1327) Fix synchronization in BlockingCallbackStore

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1327?page=com.atlassian.jira.plugin... ] Ron Sigal resolved JBREM-1327. ------------------------------ Resolution: Done > Fix synchronization in BlockingCallbackStore > -------------------------------------------- > > Key: JBREM-1327 > URL: https://issues.jboss.org/browse/JBREM-1327 > Project: JBoss Remoting > Issue Type: Bug > Affects Versions: 2.5.4.SP5 > Reporter: Ron Sigal > Assignee: Ron Sigal > Fix For: 2.5.4.SP6 > > > In org.jboss.remoting.callback.BlockingCallbackStore, add() waits on a lock which is released only when getNext() is called. so a second Callback can be added only after the first is removed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBNAME-14) Add support for remote NamingListeners

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBNAME-14?page=com.atlassian.jira.plugin.... ] Ron Sigal closed JBNAME-14. --------------------------- Resolution: Out of Date > Add support for remote NamingListeners > -------------------------------------- > > Key: JBNAME-14 > URL: https://issues.jboss.org/browse/JBNAME-14 > Project: JBoss Naming > Issue Type: Feature Request > Components: naming > Affects Versions: 5.0.0.GA > Reporter: Scott Stark > Assignee: Ron Sigal > Fix For: 6.0.0.Beta1 > > > The current EventContext support is only designed for use with NamingListeners that are in the same jvm as the naming server. We need to expand this to support remote naming clients. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBREM-1163) Evaluate FindBugs reports

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1163?page=com.atlassian.jira.plugin... ] Ron Sigal closed JBREM-1163. ---------------------------- Resolution: Out of Date > Evaluate FindBugs reports > ------------------------- > > Key: JBREM-1163 > URL: https://issues.jboss.org/browse/JBREM-1163 > Project: JBoss Remoting > Issue Type: Task > Reporter: Ron Sigal > Assignee: Ron Sigal > > http://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-findbug... > and > http://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-5.x-findbugs/... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBREM-988) Watch org.jboss.test.remoting.stream.StreamingTestCase for failures

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-988?page=com.atlassian.jira.plugin.... ] Ron Sigal closed JBREM-988. --------------------------- Resolution: Out of Date > Watch org.jboss.test.remoting.stream.StreamingTestCase for failures > ------------------------------------------------------------------- > > Key: JBREM-988 > URL: https://issues.jboss.org/browse/JBREM-988 > Project: JBoss Remoting > Issue Type: Task > Affects Versions: 2.5.4.SP3 > Reporter: Ron Sigal > Assignee: Ron Sigal > > org.jboss.test.remoting.stream.StreamingTestCase has failed a few times in hudson. Should watch for more failures. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

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 June 2018