[JBoss JIRA] (WFLY-9278) EJB Acces Timeout is ignored on SFSBs when using distributed caches
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-9278?page=com.atlassian.jira.plugin.... ]
David Lloyd updated WFLY-9278:
------------------------------
Component/s: Clustering
> 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: Clustering, 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, 3 months
[JBoss JIRA] (WFCORE-3212) Make 'required' attributes clearer when using tab completion within CLI
by Kabir Khan (JIRA)
Kabir Khan created WFCORE-3212:
----------------------------------
Summary: Make 'required' attributes clearer when using tab completion within CLI
Key: WFCORE-3212
URL: https://issues.jboss.org/browse/WFCORE-3212
Project: WildFly Core
Issue Type: Feature Request
Components: CLI
Reporter: Darran Lofthouse
Assignee: Jean-Francois Denise
The following is some example output pressing tab to reveal the parameters of 'add': -
{{[standalone@localhost:9990 /] ./subsystem=elytron/key-store=localhost:add(
! alias-filter credential-reference path provider-name providers relative-to required type }}
>From this is it not clear which are actually required.
Suggestions to make it clearer: -
* Show required / optional in different colours.
* Add something to the required attributes e.g. '*'
* Add something to the optional requirements e.g. {optional_arg}
Maybe this can go one step further and take into account arguments already added by the user, especially where attributes require another attribute or are an alternative.
Once an attribute is identified as being an alternative to another attribute maybe it should be omitted altogether from the list or maybe also have something adding to it !attr_name.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3213) CLI, Help match open/close characters
by Kabir Khan (JIRA)
Kabir Khan created WFCORE-3213:
----------------------------------
Summary: CLI, Help match open/close characters
Key: WFCORE-3213
URL: https://issues.jboss.org/browse/WFCORE-3213
Project: WildFly Core
Issue Type: Feature Request
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
In a context where we have a nesting of complex objects as operation parameters, it is difficult to match the '{' and '[' with their closing counterparts.
We could imagine something similar to IDE editor where such characters are automatically matched and colorised.
When moving the cursor onto a closing character, the opening character should be highlighted. If no match is found, then the current closing character should be also highlighted (e.g.: in red to make it clear that it is an error).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3211) Auto more/less in CLI for multi-page output
by Kabir Khan (JIRA)
Kabir Khan created WFCORE-3211:
----------------------------------
Summary: Auto more/less in CLI for multi-page output
Key: WFCORE-3211
URL: https://issues.jboss.org/browse/WFCORE-3211
Project: WildFly Core
Issue Type: Feature Request
Components: CLI
Reporter: Darran Lofthouse
Assignee: Jean-Francois Denise
Where the result of a management operation in the CLI returns multiple screens of output it would be nice if this could be automatically wrapped in a more/less type behaviour.
Similar to how git handles git log compared to how svn handles svn log.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months