[JBoss JIRA] (WFLY-3715) Async servlets cause lock timeouts for distrubutable sessions
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-3715:
----------------------------------
Summary: Async servlets cause lock timeouts for distrubutable sessions
Key: WFLY-3715
URL: https://issues.jboss.org/browse/WFLY-3715
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: 8.1.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Fix For: 8.2.0.CR1, 9.0.0.Beta1
This happens because Infinispan's BatchContainer relies on thread locals. We need to use the new Batcher capabilities used by ejb clustering for web clustering. These modules should be refactored so they can share these objects.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (WFLY-2461) refactoring of character escaping in operation parameter values
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2461?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2461:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1056933|https://bugzilla.redhat.com/show_bug.cgi?id=1056933] from POST to MODIFIED
> refactoring of character escaping in operation parameter values
> ---------------------------------------------------------------
>
> Key: WFLY-2461
> URL: https://issues.jboss.org/browse/WFLY-2461
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: CLI
> Reporter: Alexey Loubyansky
> Assignee: Alexey Loubyansky
> Fix For: 8.0.0.CR1
>
>
> There are potential issues with unescaping operation parameter values and command argument values that will be used as operation request parameter values.
> The culprit is that these values are parsed twice: first, with the general command line parser and the second time with the value type parser (which depends on the type of the value: could be list, property list, DMR, etc). Both parsers support and may perform unescaping. Which may lead to confusions and issues like WFLY-161 or WFLY-1791 and then confusing conditions in the code.
> The goal of this task is to not unescape parameter/argument values on the first parsing and leave it to the value type parsers. This concerns *only* parameter and argument value parsing, parsing of the other parts of operation requests and commands will remain as it is.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (WFLY-2964) Missing i18n
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2964?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2964:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1067024|https://bugzilla.redhat.com/show_bug.cgi?id=1067024] from POST to MODIFIED
> Missing i18n
> ------------
>
> Key: WFLY-2964
> URL: https://issues.jboss.org/browse/WFLY-2964
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB, JMX, Patching
> Affects Versions: 8.0.0.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 9.0.0.Beta1
>
>
> system-jmx/src/main/java/org/jboss/system/ServiceMBeanSupport.java
> 379 log.error(e);
> patching/src/main/java/org/jboss/as/patching/validation/PatchArtifact.java
> 102 ctx.getErrorHandler().error("Failed to load identity info for patch " + patch.getPatchId(), e);
> 116 ctx.getErrorHandler().error("Failed to load previous patch", e);
> patching/src/main/java/org/jboss/as/patching/validation/XmlFileState.java
> 51 ctx.getErrorHandler().error("File doesn't exist: " + file.getAbsolutePath());
> 56 ctx.getErrorHandler().error("Failed to parse file: " + file.getAbsolutePath(), e);
> patching/src/main/java/org/jboss/as/patching/validation/PatchElementProviderArtifact.java
> 84 ctx.getErrorHandler().error("Layer not found: " + metadata.getName());
> patching/src/main/java/org/jboss/as/patching/runner/IdentityPatchContext.java
> 435 PatchLogger.ROOT_LOGGER.warnf(e, "failed to undo change (%s)", modification);
> ejb3/src/main/java/org/jboss/as/ejb3/tx/CMTTxInterceptor.java
> 169 EjbLogger.ROOT_LOGGER.error(t);
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (WFLY-3711) Topology updates of EJBClient ClusterContexts not being processed correctly after failover
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-3711?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz updated WFLY-3711:
--------------------------------------
Summary: Topology updates of EJBClient ClusterContexts not being processed correctly after failover (was: Topology updates of EJBClient ClusterContexts not being updated correctly after failover)
> Topology updates of EJBClient ClusterContexts not being processed correctly after failover
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-3711
> URL: https://issues.jboss.org/browse/WFLY-3711
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 9.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
>
> ClusterContexts are used by EJBClient to keep track of the current set of nodes in a cluster, so that if an EJBClient invocation fails on one node, it may failover to another node in the same cluster. The ClusterContext is made up of ClusterNodeManagers which are responsible for setting up the connections between the EJBClient and the nodes in the cluster.
> Cluster topology updates are sent to registered EJBClients whenever the cluster topology changes (nodes join, nodes leave a cluster). Thse topology updates are processed on the client side by ClusterTopologyUpdateHandler and are used to update the current contents of the associated ClusterContext held on the client.
> The current implementation of the handling of topology updates does not correctly handle the addition/removal of ClusterNodeManagers from the cluster context - namely, rather than check whether or not a new ClusterNodeManager really needs to be added, ClusterNodeManagers are added for every node in the received topology update, leading to many unnecessary EJBReceivers and their channels being created.
> The logs show that up to 18 cluster node manager instances may be created, have their EJBReceivers registered and channels to the remote node created, when only one node has been added to the cluster.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months