[JBoss JIRA] (WFLY-9395) Move ClusteringRequirement to the public API module
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-9395?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-9395:
-------------------------------
Issue Type: Enhancement (was: Bug)
> Move ClusteringRequirement to the public API module
> ---------------------------------------------------
>
> Key: WFLY-9395
> URL: https://issues.jboss.org/browse/WFLY-9395
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 11.0.0.CR1
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
> Priority: Major
>
> Currently the user needs to rely on using the capability name as service name to establish a dependency, e.g.:
> {code:java}
> policy.createSingletonServiceBuilder(SINGLETON_SERVICE_NAME, service)
> .build(serviceActivatorContext.getServiceTarget())
> .addDependency(ServiceName.parse("org.wildfly.clustering.default-group"), Group.class, group)
> .install();
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-9278) EJB Access Timeout is ignored on SFSBs when using distributed caches
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-9278?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-9278:
--------------------------------------
Triage 2019-04-04: this is an EJB issue, taking clustering off the list.
> EJB Access 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
> Assignee: Tomasz Adamski
> Priority: Major
> 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 expected, 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.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-9278) EJB Access Timeout is ignored on SFSBs when using distributed caches
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-9278?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-9278:
-------------------------------
Component/s: (was: Clustering)
> EJB Access 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
> Assignee: Tomasz Adamski
> Priority: Major
> 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 expected, 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.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-9278) EJB Access Timeout is ignored on SFSBs when using distributed caches
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-9278?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-9278:
---------------------------------
Description:
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 expected, 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.
was:
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.
> EJB Access 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: Clustering, EJB
> Affects Versions: 11.0.0.CR1
> Reporter: Bernhard Hablesreiter
> Assignee: Tomasz Adamski
> Priority: Major
> 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 expected, 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.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-8939) Clustering creating a large number of ServiceName instances
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-8939?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-8939 at 4/4/19 3:07 PM:
--------------------------------------------------------------
Triage 2019-04-04: fixing classification to 'Enhancement'.
was (Author: rhusar):
Triage 2019-04-04: fixing classification to 'Task'.
> Clustering creating a large number of ServiceName instances
> -----------------------------------------------------------
>
> Key: WFLY-8939
> URL: https://issues.jboss.org/browse/WFLY-8939
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Reporter: Brian Stansberry
> Assignee: Paul Ferraro
> Priority: Minor
> Attachments: servicenameparse.txt
>
>
> A downside of the shift to capability-driven service wiring has been a significant increase in memory use related to ServiceName instances. A ServiceName is basically a linked list of a string wrapper objects, with the wrapper objects sharable between lists. In the old way of hand creating ServiceNames the wrapper objects would typically be shared widely since a new name would be created by appending a new wrapper to the last element in an existing chain.
> With capabilities, this breaks down as ServiceNames are being created by parsing a dot-separated string. Names created that way no longer share elements and multiple instances of strings like "org" and "wildlfy" end up being kept in memory.
> https://issues.jboss.org/browse/WFCORE-2895 is about improving this in the kernel. But analyzing the result of my effort there didn't show as big of an impact as I expected. Investigating why, I see a lot of uses of ServiceName.parse in the clustering code, which will have the same effect. I'll attach the results of "git grep ServiceName.parse" against the full WildFly code base.
> I don't know how easily this can be resolved. The kernel may need to provide a capability-name to ServiceName utility that can do optimizations.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-8939) Clustering creating a large number of ServiceName instances
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-8939?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-8939:
-------------------------------
Issue Type: Enhancement (was: Bug)
> Clustering creating a large number of ServiceName instances
> -----------------------------------------------------------
>
> Key: WFLY-8939
> URL: https://issues.jboss.org/browse/WFLY-8939
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Reporter: Brian Stansberry
> Assignee: Paul Ferraro
> Priority: Minor
> Attachments: servicenameparse.txt
>
>
> A downside of the shift to capability-driven service wiring has been a significant increase in memory use related to ServiceName instances. A ServiceName is basically a linked list of a string wrapper objects, with the wrapper objects sharable between lists. In the old way of hand creating ServiceNames the wrapper objects would typically be shared widely since a new name would be created by appending a new wrapper to the last element in an existing chain.
> With capabilities, this breaks down as ServiceNames are being created by parsing a dot-separated string. Names created that way no longer share elements and multiple instances of strings like "org" and "wildlfy" end up being kept in memory.
> https://issues.jboss.org/browse/WFCORE-2895 is about improving this in the kernel. But analyzing the result of my effort there didn't show as big of an impact as I expected. Investigating why, I see a lot of uses of ServiceName.parse in the clustering code, which will have the same effect. I'll attach the results of "git grep ServiceName.parse" against the full WildFly code base.
> I don't know how easily this can be resolved. The kernel may need to provide a capability-name to ServiceName utility that can do optimizations.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-8939) Clustering creating a large number of ServiceName instances
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-8939?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-8939:
--------------------------------------
Triage 2019-04-04: fixing classification to 'Task'.
> Clustering creating a large number of ServiceName instances
> -----------------------------------------------------------
>
> Key: WFLY-8939
> URL: https://issues.jboss.org/browse/WFLY-8939
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Brian Stansberry
> Assignee: Paul Ferraro
> Priority: Minor
> Attachments: servicenameparse.txt
>
>
> A downside of the shift to capability-driven service wiring has been a significant increase in memory use related to ServiceName instances. A ServiceName is basically a linked list of a string wrapper objects, with the wrapper objects sharable between lists. In the old way of hand creating ServiceNames the wrapper objects would typically be shared widely since a new name would be created by appending a new wrapper to the last element in an existing chain.
> With capabilities, this breaks down as ServiceNames are being created by parsing a dot-separated string. Names created that way no longer share elements and multiple instances of strings like "org" and "wildlfy" end up being kept in memory.
> https://issues.jboss.org/browse/WFCORE-2895 is about improving this in the kernel. But analyzing the result of my effort there didn't show as big of an impact as I expected. Investigating why, I see a lot of uses of ServiceName.parse in the clustering code, which will have the same effect. I'll attach the results of "git grep ServiceName.parse" against the full WildFly code base.
> I don't know how easily this can be resolved. The kernel may need to provide a capability-name to ServiceName utility that can do optimizations.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-8939) Clustering creating a large number of ServiceName instances
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-8939?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-8939:
-------------------------------
Priority: Minor (was: Major)
> Clustering creating a large number of ServiceName instances
> -----------------------------------------------------------
>
> Key: WFLY-8939
> URL: https://issues.jboss.org/browse/WFLY-8939
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Brian Stansberry
> Assignee: Paul Ferraro
> Priority: Minor
> Attachments: servicenameparse.txt
>
>
> A downside of the shift to capability-driven service wiring has been a significant increase in memory use related to ServiceName instances. A ServiceName is basically a linked list of a string wrapper objects, with the wrapper objects sharable between lists. In the old way of hand creating ServiceNames the wrapper objects would typically be shared widely since a new name would be created by appending a new wrapper to the last element in an existing chain.
> With capabilities, this breaks down as ServiceNames are being created by parsing a dot-separated string. Names created that way no longer share elements and multiple instances of strings like "org" and "wildlfy" end up being kept in memory.
> https://issues.jboss.org/browse/WFCORE-2895 is about improving this in the kernel. But analyzing the result of my effort there didn't show as big of an impact as I expected. Investigating why, I see a lot of uses of ServiceName.parse in the clustering code, which will have the same effect. I'll attach the results of "git grep ServiceName.parse" against the full WildFly code base.
> I don't know how easily this can be resolved. The kernel may need to provide a capability-name to ServiceName utility that can do optimizations.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month