August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9278) EJB Acces Timeout is ignored on SFSBs when using distributed caches

by Bernhard Hablesreiter (JIRA)

Bernhard Hablesreiter created WFLY-9278: ------------------------------------------- Summary: EJB Acces Timeout is ignored on SFSBs when using distributed caches Key: WFLY-9278 URL: https://issues.jboss.org/browse/WFLY-9278 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 11.0.0.CR1 Reporter: Bernhard Hablesreiter Attachments: wildfly-request-test.zip When using distributed caches on Stateful Session Beans, the configured access timeout is ignored. However, the caches acquire-timeout is used instead, leading to a "org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after x seconds". The configuration: {code:xml} <session-bean> <stateless> <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/> </stateless> <stateful default-access-timeout="2000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/> <singleton default-access-timeout="2000"/> </session-bean> <pools> <bean-instance-pools> <strict-max-pool name="slsb-strict-max-pool" derive-size="from-worker-pools" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/> <strict-max-pool name="mdb-strict-max-pool" derive-size="from-cpu-count" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/> </bean-instance-pools> </pools> <caches> <cache name="simple"/> <cache name="distributable" passivation-store-ref="infinispan" aliases="passivating clustered"/> </caches> ... <subsystem xmlns="urn:jboss:domain:infinispan:4.0"> ... <cache-container name="ejb" aliases="sfsb" default-cache="passivation" module="org.wildfly.clustering.ejb.infinispan"> <local-cache name="passivation"> <locking isolation="REPEATABLE_READ" acquire-timeout="10000"/> <transaction mode="BATCH" /> <file-store passivation="true" purge="true"/> </local-cache> </cache-container> ... </subsystem> {code} With the above configuration, any access to a @Stateful-component does not timeout after 2 seconds, but the 10 seconds configured on the infinispan-cache. I have attached a simple JSF web application as an eclipse project to reproduce the problem. The application calls a method on a sfsb, increments a counter and waits for 300ms. If one sends multiple request at the same time (e.g. by pressing F5 repeatedly), the problem can easily be reproduced after a few seconds. If the cache-ref is set to "simple" the configured access timeout works as exptected, however the access to the stateful bean does not appear to be in sync with the requests the client sent. We came around this issue when trying to migrate vom WF9 to WF10 (see also this forum post: https://developer.jboss.org/thread/266303). When the cache-ref is set to "distrubted", the requests are handled correctly/in correct order (in WF9 this was also the case with cache-ref "simple"), but the access timeout is ignored. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9277) Wildfly logs warning "WFLYEJB0463: Invalid transaction attribute" for Stateful components with CDI lifecycle methods

by Bernhard Hablesreiter (JIRA)

Bernhard Hablesreiter created WFLY-9277: ------------------------------------------- Summary: Wildfly logs warning "WFLYEJB0463: Invalid transaction attribute" for Stateful components with CDI lifecycle methods Key: WFLY-9277 URL: https://issues.jboss.org/browse/WFLY-9277 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 11.0.0.CR1 Environment: WFLY 11.0.0.CR1, JDK8 Reporter: Bernhard Hablesreiter Wildlfy logs a warning "WFLYEJB0463: Invalid transaction attribute type REQUIRED on SFSB lifecycle method Method postConstruct() of class class com.test.Test, valid types are REQUIRES_NEW and NOT_SUPPORTED. Method will be treated as NOT_SUPPORTED." for @Stateful-components with CDI lifecycle annotations, even if the Class does not define any Transaction-Attributes: {code:java} @Named @SessionScoped @Stateful public class Test implements Serializable { private static final long serialVersionUID = -2055975290009863989L; @PostConstruct private void postConstruct() {} } {code} The warning is only created when the @PostConstruct-method is on the class itself and not inherited (which does not make any difference). If the class extends another class, which declares a @PostConstruct-method, the warning does not appear. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently

by Nuno Godinho de Matos (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ] Nuno Godinho de Matos commented on WFCORE-3210: ----------------------------------------------- Understood. Nur now i Hope it is clear what we want to achieve. Das for Stack traced there are none. Because you have at logging Level something exploding and the logging Implantation seems to Default to Log to Standard Error the Problem. As for the Module configuration. It Looks complucated as a result of multiple Experiments to try to ban org jboss log4j from sneaking in. I for sure die Not star With a Module Kopplung linke a Patch Work. That is where i ended up. Thanks. > Wildfly module isolation not working consistently > ------------------------------------------------- > > Key: WFCORE-3210 > URL: https://issues.jboss.org/browse/WFCORE-3210 > Project: WildFly Core > Issue Type: Bug > Components: Logging, Modules > Affects Versions: 2.2.0.Final > Reporter: Nuno Godinho de Matos > > There is an underministic bug on the module layer of wildfly, whereby the boot logic of the application server is not ensured to give the appropriate module isolation - which can lead to unexpected boot classpath problems. > An example of this phenomena is given on the wildfly forum thread: > https://developer.jboss.org/thread/275839 > In this example, we have the logging subsystem setup to use a custome handler. > The custom handler wishes to have acces to the JUL extension classes on the org.jboss.logmanger module, but wishes to do have no relationship with the org.apache.log4j packages associated to the wildfly org.jboss.log4j module. > What we see in this example is that an application gets from wildfly mixed behavior. > Most of the time, during boot, the processes works without problem, where the custom handler runs isolated from the undersired log4j libraries within wildfly. > But other times the application boot procedure will not go smoothly with the custom handler having processes routing JUL LogRecords events into the bundled log4j because the application server has loaded some of the classes that exist the org.jboss.log4j module. > And as we know when the same class is loaded by different class loaders, then that class that orinates from class loader A cannot be assigned to the corresponding class of class loader B, even if the classes are exactly the same. > This is not an isolated issue. > There are also open issues on the wildfly forum reporting on startup problems on the logging subsystme where sometimes the LogManager class had not yet been loaded, and sometimes this issue goes away. > This is an indication of some deep issue engrained into the module loading, where the module isolation behavior is not ensured to work all the time and that the boot procedure is not deterministically reliable. > It should not be that the application server some time starts successfully and others not. > Booting wildfly should always result in the same outcode. > Problems of this nature with class loading problems should either always happen if the configuration is not done properly or never happen if the configuration is proper. > In the case of thread: > https://developer.jboss.org/thread/275839 > Our belief is that the configuration is doing all it possible can to request the necessary module isolation from base packages and the outcome where log4j class load problems take place should never be allowed to happen. > Many thanks. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently

by jaikiran pai (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ] jaikiran pai commented on WFCORE-3210: -------------------------------------- [~nuno.godinhomatos], To some extent I understand what you are trying to achieve. However, the way you have presented it, makes it very difficult to understand or narrow this down to the actual issue. For example, that module.xml that you have in one of the comments in this JIRA, to me, looks too complicated. And I can't imagine (even with the comments in that file) why it's defined in that manner. As David noted, tell us what you are trying to achieve, not what WildFly is doing (I really don't mean it as some kind of insult). Provide exact details like the entire exception stacktrace. You have been trying to explain to us what WildFly internally does and what it shouldn't do. It's fine to explain that, but there needs to be a separate precise explanation which shows us what your configs are, what exception stacktraces you run into so that we too can either come to the same conclusion about what WildFly is doing or figure out if there's something else going on. P.S: It's also better to use formatting while posting logs, code or xml configurations so that it's easier to read. > Wildfly module isolation not working consistently > ------------------------------------------------- > > Key: WFCORE-3210 > URL: https://issues.jboss.org/browse/WFCORE-3210 > Project: WildFly Core > Issue Type: Bug > Components: Logging, Modules > Affects Versions: 2.2.0.Final > Reporter: Nuno Godinho de Matos > > There is an underministic bug on the module layer of wildfly, whereby the boot logic of the application server is not ensured to give the appropriate module isolation - which can lead to unexpected boot classpath problems. > An example of this phenomena is given on the wildfly forum thread: > https://developer.jboss.org/thread/275839 > In this example, we have the logging subsystem setup to use a custome handler. > The custom handler wishes to have acces to the JUL extension classes on the org.jboss.logmanger module, but wishes to do have no relationship with the org.apache.log4j packages associated to the wildfly org.jboss.log4j module. > What we see in this example is that an application gets from wildfly mixed behavior. > Most of the time, during boot, the processes works without problem, where the custom handler runs isolated from the undersired log4j libraries within wildfly. > But other times the application boot procedure will not go smoothly with the custom handler having processes routing JUL LogRecords events into the bundled log4j because the application server has loaded some of the classes that exist the org.jboss.log4j module. > And as we know when the same class is loaded by different class loaders, then that class that orinates from class loader A cannot be assigned to the corresponding class of class loader B, even if the classes are exactly the same. > This is not an isolated issue. > There are also open issues on the wildfly forum reporting on startup problems on the logging subsystme where sometimes the LogManager class had not yet been loaded, and sometimes this issue goes away. > This is an indication of some deep issue engrained into the module loading, where the module isolation behavior is not ensured to work all the time and that the boot procedure is not deterministically reliable. > It should not be that the application server some time starts successfully and others not. > Booting wildfly should always result in the same outcode. > Problems of this nature with class loading problems should either always happen if the configuration is not done properly or never happen if the configuration is proper. > In the case of thread: > https://developer.jboss.org/thread/275839 > Our belief is that the configuration is doing all it possible can to request the necessary module isolation from base packages and the outcome where log4j class load problems take place should never be allowed to happen. > Many thanks. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently

by Nuno Godinho de Matos (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ] Nuno Godinho de Matos commented on WFCORE-3210: ----------------------------------------------- Hi James. Thank you so much. I will try to give you tomorrow a pacakage with a Module oour Jul Router i was told this is eine. And a Basic Domain. Theb when i believe you need to play With Start via Script vs via Eclipse. That is how i am able to make it fail. And probabaly a critical Element is that my Module for Jul Routing needs Access to Just One class of the core logmanager Module. The ext logrecord for Jul. So the Module i have for Routing triew to Import Just this One class from org.jboss.logmanager. and i believe the key to the phenomena must be there... I will give you the pacakage tomorrow. Many thanks. Kindest regards. > Wildfly module isolation not working consistently > ------------------------------------------------- > > Key: WFCORE-3210 > URL: https://issues.jboss.org/browse/WFCORE-3210 > Project: WildFly Core > Issue Type: Bug > Components: Logging, Modules > Affects Versions: 2.2.0.Final > Reporter: Nuno Godinho de Matos > > There is an underministic bug on the module layer of wildfly, whereby the boot logic of the application server is not ensured to give the appropriate module isolation - which can lead to unexpected boot classpath problems. > An example of this phenomena is given on the wildfly forum thread: > https://developer.jboss.org/thread/275839 > In this example, we have the logging subsystem setup to use a custome handler. > The custom handler wishes to have acces to the JUL extension classes on the org.jboss.logmanger module, but wishes to do have no relationship with the org.apache.log4j packages associated to the wildfly org.jboss.log4j module. > What we see in this example is that an application gets from wildfly mixed behavior. > Most of the time, during boot, the processes works without problem, where the custom handler runs isolated from the undersired log4j libraries within wildfly. > But other times the application boot procedure will not go smoothly with the custom handler having processes routing JUL LogRecords events into the bundled log4j because the application server has loaded some of the classes that exist the org.jboss.log4j module. > And as we know when the same class is loaded by different class loaders, then that class that orinates from class loader A cannot be assigned to the corresponding class of class loader B, even if the classes are exactly the same. > This is not an isolated issue. > There are also open issues on the wildfly forum reporting on startup problems on the logging subsystme where sometimes the LogManager class had not yet been loaded, and sometimes this issue goes away. > This is an indication of some deep issue engrained into the module loading, where the module isolation behavior is not ensured to work all the time and that the boot procedure is not deterministically reliable. > It should not be that the application server some time starts successfully and others not. > Booting wildfly should always result in the same outcode. > Problems of this nature with class loading problems should either always happen if the configuration is not done properly or never happen if the configuration is proper. > In the case of thread: > https://developer.jboss.org/thread/275839 > Our belief is that the configuration is doing all it possible can to request the necessary module isolation from base packages and the outcome where log4j class load problems take place should never be allowed to happen. > Many thanks. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9275) EJB client(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client)

by Loren Chang (JIRA)

[ https://issues.jboss.org/browse/WFLY-9275?page=com.atlassian.jira.plugin.... ] Loren Chang updated WFLY-9275: ------------------------------ Description: This test code on "public static void main" is ok, but fail on war/ear EJB client API Version:wildfly-naming-client-1.0.0.Beta13.jar、jboss-remote-naming-2.0.4.Final.jar was: This test code on "public static void main" is ok, but fail on war/ear naming > EJB client(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client) > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-9275 > URL: https://issues.jboss.org/browse/WFLY-9275 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Loren Chang > Attachments: WildFlyBug.png > > > This test code on "public static void main" is ok, but fail on war/ear > EJB client API Version:wildfly-naming-client-1.0.0.Beta13.jar、jboss-remote-naming-2.0.4.Final.jar -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9275) EJB client(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client)

by Loren Chang (JIRA)

[ https://issues.jboss.org/browse/WFLY-9275?page=com.atlassian.jira.plugin.... ] Loren Chang updated WFLY-9275: ------------------------------ Summary: EJB client(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client) (was: naming api(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client)) > EJB client(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client) > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-9275 > URL: https://issues.jboss.org/browse/WFLY-9275 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Loren Chang > Attachments: WildFlyBug.png > > > This test code on "public static void main" is ok, but fail on war/ear > naming -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9275) naming api(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client)

by Loren Chang (JIRA)

[ https://issues.jboss.org/browse/WFLY-9275?page=com.atlassian.jira.plugin.... ] Loren Chang updated WFLY-9275: ------------------------------ Description: This test code on "public static void main" is ok, but fail on war/ear naming was:This test code on "public static void main" is ok, but fail on war/ear > naming api(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client) > ----------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9275 > URL: https://issues.jboss.org/browse/WFLY-9275 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Loren Chang > Attachments: WildFlyBug.png > > > This test code on "public static void main" is ok, but fail on war/ear > naming -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9275) naming api(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client)

by Loren Chang (JIRA)

[ https://issues.jboss.org/browse/WFLY-9275?page=com.atlassian.jira.plugin.... ] Loren Chang updated WFLY-9275: ------------------------------ Summary: naming api(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client) (was: wildfly naming api(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client)) > naming api(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client) > ----------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9275 > URL: https://issues.jboss.org/browse/WFLY-9275 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Loren Chang > Attachments: WildFlyBug.png > > > This test code on "public static void main" is ok, but fail on war/ear -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9275) wildfly naming api(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client)

by Loren Chang (JIRA)

[ https://issues.jboss.org/browse/WFLY-9275?page=com.atlassian.jira.plugin.... ] Loren Chang updated WFLY-9275: ------------------------------ Description: This test code on "public static void main" is ok, but fail on war/ear > wildfly naming api(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client) > ------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9275 > URL: https://issues.jboss.org/browse/WFLY-9275 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Loren Chang > Attachments: WildFlyBug.png > > > This test code on "public static void main" is ok, but fail on war/ear -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 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 August 2017