[JBoss JIRA] (JGRP-1910) MERGE3: Do not lose any members from view during a series of merges
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/JGRP-1910?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on JGRP-1910:
-----------------------------------
[~belaban] Any chance you have managed to model MERGE3 in +Cal?
So the problem is probably that a node accepts a merge view from merge leader X after accepting another view from merge leader Y. We can't eliminate two leaders being chosen concurrently, but a view that's not based on current view should be rejected.
> MERGE3: Do not lose any members from view during a series of merges
> -------------------------------------------------------------------
>
> Key: JGRP-1910
> URL: https://issues.jboss.org/browse/JGRP-1910
> Project: JGroups
> Issue Type: Bug
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.6.3
>
> Attachments: SplitMergeFailFastTest.java, SplitMergeTest.java
>
>
> When connection between nodes is re-established, MERGE3 should merge the cluster together. This often does not involve a single MergeView but a series of such events. The problematic property of this protocol is that some of those views can lack certain members, though these are reachable.
> This causes problem in Infinispan since the cache cannot be fully rebalanced before another merge arrives, and all owners of certain segment can be gradually removed (and added again) to the view, while this is not detected as partition but crashed nodes -> losing all owners means data loss.
> Removing members from view should be the role of FDx protocols, not MERGEx.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (JGRP-1910) MERGE3: Do not lose any members from view during a series of merges
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1910?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1910:
--------------------------------
To reduces the chances of multiple parallel merges, we could say that the _merge leader_ are collected from all views, e.g.
{noformat}
0 -> [0|5] (4) [0,1,2,3]
5 -> [5|5] (2) [5,6]
9 -> [8|5] (2) [8,9]
{noformat}
Here, the current algorithm to pick merge leaders only collects view creators that actually *sent* the {{INFO}} message: 0 and 5, but *not* 8. The reason is that we want to pick responses from live members, from which we received {{INFO}} messages, and not from members that were proposed by other members and might be incorrect.
For example, 8 might have crashed, but 9 still has it in its view. We don't want to wait until 8 has been exluded by failure detection.
If 8 was indeed dead and we collected 0, 5 and 8 as merge leaders and 8 became merge leader (by sorting 0, 5 and 8 (UUID-wise) and taking the first one), then we'd waste merge rounds until 8 was actualy declared dead and removed from the views.
> MERGE3: Do not lose any members from view during a series of merges
> -------------------------------------------------------------------
>
> Key: JGRP-1910
> URL: https://issues.jboss.org/browse/JGRP-1910
> Project: JGroups
> Issue Type: Bug
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.6.3
>
> Attachments: SplitMergeFailFastTest.java, SplitMergeTest.java
>
>
> When connection between nodes is re-established, MERGE3 should merge the cluster together. This often does not involve a single MergeView but a series of such events. The problematic property of this protocol is that some of those views can lack certain members, though these are reachable.
> This causes problem in Infinispan since the cache cannot be fully rebalanced before another merge arrives, and all owners of certain segment can be gradually removed (and added again) to the view, while this is not detected as partition but crashed nodes -> losing all owners means data loss.
> Removing members from view should be the role of FDx protocols, not MERGEx.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (WFLY-4194) Deprecate default-stack JGroups subsystem attribute
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-4194?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-4194.
------------------------------
Fix Version/s: 9.0.0.Beta1
Resolution: Done
Fixed already.
> Deprecate default-stack JGroups subsystem attribute
> ---------------------------------------------------
>
> Key: WFLY-4194
> URL: https://issues.jboss.org/browse/WFLY-4194
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 9.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 9.0.0.Beta1
>
>
> The original purpose of the default-stack attribute was to provide a default ChannelFactory implementation. However, with the introduction of fork channels, there are now 2 candidate for a default ChannelFactory:
> 1. The JChannelFactory of the default stack.
> 2. The ForkChannelFactory of the default channel.
> #2 is the better option - and is what Infinispan transports use by default.
> This would require that the stack attribute of a channel is required (currently, it is optional and defaults to the default-stack).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (JGRP-1910) MERGE3: Do not lose any members from view during a series of merges
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1910?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1910:
--------------------------------
OK, so the problem is this: if we have a split like the one below:
{noformat}
0: [0|9] (3) [0, 2, 1]
1: [0|9] (3) [0, 2, 1]
2: [0|9] (3) [0, 2, 1]
3: [3|9] (2) [3, 4]
4: [3|9] (2) [3, 4]
5: [5|10] (3) [5, 6, 7]
6: [5|10] (3) [5, 6, 7]
7: [5|10] (3) [5, 6, 7]
8: [9|9] (2) [9, 8]
9: [9|9] (2) [9, 8]
{noformat}
, members send {{INFO}} messages (in {{MERGE3}}) with the view-id, e.g. 7 sends {{\[5|10\]}}.
Every member multicasts an {{INFO}} message at a random interval {{\[MERGE3.min_interval..MERGE3_max_interval\]}}.
The coordinators of the subclusters (0, 3, 5 and 9) check every {MERGE3.check_interval}} ms if they've received different view-ids and initiate a merge if so.
The problem with your test is that it drops {{INFO}} messages (not retransmitted as {{MERGE3}} is below {{UNICASTX}} and {{NAKACKX}}, so when a coordinator starts the view-id check, it may not have received all view-ids.
Example:
{noformat}
5: I will be the merge leader. Starting the merge task. Coords: [5], views: {5=[5|10] (3) [5, 6, 7], 1=[0|9] (3) [0, 2, 1]}
9: I will be the merge leader. Starting the merge task. Coords: [9, 3], views: {4=[3|9] (2) [3, 4], 9=[9|9] (2) [9, 8], 3=[3|9] (2) [3, 4], 7=[5|11] (6) [5, 0, 2, 1, 6, 7]}
{noformat}
Here, we can see that 5 and 9 were merge leaders and started merges at almost the same time. Depending on which merge leader is able to contact more members, there will be more than 1 merge needed to end up with a fully merged view.
E.g if 5 succeeds in contacting itself, 3 and 0 *before 9 contacts them* , then a merge will ensue including 0, 3 and 5. 9 will not merge with anyone else, as it started a merge on its own and therefore rejects 5's merge request.
The problem can be mitigated (but not eliminated altogether) by reducing {{min_interval}} and {{max_interval}} and increasing {{check_interval}} in {{MERGE3}}: this way, coordinators are more likely to get more {{INFO}} messages from everyone (despite the message drops) and this reduces the chances of multiple merge leaders being chosen.
> MERGE3: Do not lose any members from view during a series of merges
> -------------------------------------------------------------------
>
> Key: JGRP-1910
> URL: https://issues.jboss.org/browse/JGRP-1910
> Project: JGroups
> Issue Type: Bug
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.6.3
>
> Attachments: SplitMergeFailFastTest.java, SplitMergeTest.java
>
>
> When connection between nodes is re-established, MERGE3 should merge the cluster together. This often does not involve a single MergeView but a series of such events. The problematic property of this protocol is that some of those views can lack certain members, though these are reachable.
> This causes problem in Infinispan since the cache cannot be fully rebalanced before another merge arrives, and all owners of certain segment can be gradually removed (and added again) to the view, while this is not detected as partition but crashed nodes -> losing all owners means data loss.
> Removing members from view should be the role of FDx protocols, not MERGEx.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (WFLY-3764) Problem with Infinispan and transactions
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3764?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-3764.
------------------------------
Resolution: Duplicate Issue
Duplicate of https://issues.jboss.org/browse/WFLY-3718
> Problem with Infinispan and transactions
> -----------------------------------------
>
> Key: WFLY-3764
> URL: https://issues.jboss.org/browse/WFLY-3764
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 8.0.0.Final, 8.1.0.Final
> Environment: Operating System: Redhat 6
> jdk1.7.0_51
> x86_64
> Reporter: Joel Sebastian
> Assignee: Paul Ferraro
> Labels: domain, httpsession, infinispan, transactions, web
>
> We are using Jasing CAS 3.5.2 for Single Sign On purposes deployed on a server in a Wildfly 8.0.0 Final domain (yesterday we upgraded to 8.1.0 Final).
> The application is working just fine, but in sometimes we detect this error:
> 2014-08-22 00:30:50,365 ERROR [io.undertow.request] (default task-85) UT005023: Exception handling request to /SSO/login: org.springframework.web.util.NestedServletException: Request processing failed; nested exception is java.lang.IllegalArgumentException: Cookie name "comment" is a reserved token
> After this error the applications starts to fail with this error:
> 2014-08-22 00:31:24,387 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-91) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [15 seconds] on key [Urkr0TVHiwJ95KJnuhz9IB9n] for requestor [GlobalTransaction:<master:sso-server-1/web>:308:local]! Lock held by [GlobalTransaction:<master:sso-server-1/web>:296:local]
> 2014-08-22 00:31:24,407 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-91) ISPN000136: Execution error: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=308}, status=1} is not in a valid state to be invoking cache operations on.
> After this happens we need to restart the server, because the application cannot be restored from those errors.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (WFLY-4416) Cannot obtain DOMImplementationRegistry instance
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4416?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-4416:
-----------------------------------
can same problem be reproduced in master as well?
> Cannot obtain DOMImplementationRegistry instance
> ------------------------------------------------
>
> Key: WFLY-4416
> URL: https://issues.jboss.org/browse/WFLY-4416
> Project: WildFly
> Issue Type: Bug
> Components: XML Frameworks
> Affects Versions: 8.2.0.Final
> Reporter: Thomas Diesler
> Assignee: Jason Greene
>
> {code}
> testDOMImplementationRegistry(org.jboss.as.test.smoke.xml.DOMImplementationRegistryTestCase) Time elapsed: 0.09 sec <<< ERROR!
> java.lang.ClassNotFoundException: com.sun.org.apache.xerces.internal.dom.DOMXSImplementationSourceImpl from [Module "deployment.dom-registry-test:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134)
> at org.w3c.dom.bootstrap.DOMImplementationRegistry.newInstance(DOMImplementationRegistry.java:182)
> at org.jboss.as.test.smoke.xml.DOMImplementationRegistryTestCase.testDOMImplementationRegistry(DOMImplementationRegistryTestCase.java:52)
> {code}
> CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/391
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (WFLY-3664) Exceptions during download of webstart libraries
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3664?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-3664.
-------------------------------
Fix Version/s: 9.0.0.Beta1
Resolution: Partially Completed
As discussed on forums, majority of this problem is in original JNPL Servlet implementation.
Pino Silvaggio put together fixed version of servlet and put it on github: https://github.com/bitstrings/jnlp-servlet
With that version problems are gone.
> Exceptions during download of webstart libraries
> ------------------------------------------------
>
> Key: WFLY-3664
> URL: https://issues.jboss.org/browse/WFLY-3664
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: Windows 7 (64bit), Windows Server 2012 R2 (64bit)
> Reporter: Markus Schwarz
> Assignee: Tomaz Cerar
> Priority: Minor
> Fix For: 9.0.0.Beta1
>
> Attachments: demo-src.zip, lsof.log.gz, server.log, server.log.gz
>
>
> I have a webstart application using the JnlpDownloadServlet. If the client cache is empty, launching the JNLP will download the libraries. The webstart application works as expected, but in the server logs there are many errors regarding download of the libraries.
> Just to mention: Not always the same libraries are listed with erros in the logs files. Sometimes I even got now exceptions.
> For my tests I used Wildfly 8.1.0.FINAL as well as a nightly build from 24. of July without any further changes of the configuration files (https://ci.jboss.org/hudson/job/WildFly-latest-master/).
> I tested it under Windows 7 and Windows Server 2012 R2. The demo contains an older JnlpDownloadServlet, but I tested it also with the one coming with JDK 7u65.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (WFLY-2999) AJP connector request body stream is wrong mixed
by Jarno Komulainen (JIRA)
[ https://issues.jboss.org/browse/WFLY-2999?page=com.atlassian.jira.plugin.... ]
Jarno Komulainen commented on WFLY-2999:
----------------------------------------
We are probably facing this issue on Wildfly 8.2. Which undertow version contains this fix and can we upgrade wildfly 8.2 undertow module to this version?
> AJP connector request body stream is wrong mixed
> ------------------------------------------------
>
> Key: WFLY-2999
> URL: https://issues.jboss.org/browse/WFLY-2999
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final
> Environment: Apahce HTTPD 2.2.23 + MOD_CLUSTER 1.3 Final + WildFly 8 Final
> Reporter: JuYeon Yu
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Alpha1
>
>
> Seem to have a problem with the AJP Connector.
> When client(Browser) send request has many parameter, sometime received content is different.
> ex)
> Request Body is:
> dataJson={"crfpage_type":["CRF"],"qst_rowno":["7148#0#0","7141#0#0","7143#0#0","7144#0#0","7145#0#0","7146#0#0","7147#0#0","7123#0#0","7125#0#0","7126#0#0","7127#0#0","7128#0#0","7129#0#0","7130#0#0","7131#0#0","7132#0#0","7133#0#0","7134#0#0","7135#0#0","7136#0#0","7137#0#0","7138#0#0","7139#0#0","7140#0#0","7117#0#0","7119#0#0","7120#0#0","7121#0#0","7122#0#0"],"item_7148_16445_0_0":[""],"_item_7141_16466_0_0":[""],"item_7143_16462_0_0":["RBC"],"item_7143_16463_0_0":[""],"item_7143_16464_0_0":[""],"item_7143_16464_0_0_r":[""],"item_7143_16465_0_0":[""],"item_7144_16458_0_0":["Hemoglobin"],"item_7144_16459_0_0":[""],"item_7144_16460_0_0":[""],"item_7144_16460_0_0_r":[""],"item_7144_16461_0_0":[""],"item_7145_16454_0_0":["Hematocrit"],"item_7145_16455_0_0":[""],"item_7145_16456_0_0":[""],"item_7145_16456_0_0_r":[""],"item_7145_16457_0_0":[""],"item_7146_16450_0_0":["Platelet"],"item_7146_16451_0_0":[""],"item_7146_16452_0_0":[""],"item_7146_16452_0_0_r":[""],"item_7146_16453_0_0":[""],"item_7147_16446_0_0":["WBC"],"item_7147_16447_0_0":[""],"item_7147_16448_0_0":[""],"item_7147_16448_0_0_r":[""],"item_7147_16449_0_0":[""],"_item_7123_16531_0_0":[""],"item_7125_16527_0_0":["Calcium"],"item_7125_16528_0_0":[""],"item_7125_16529_0_0":[""],"item_7125_16529_0_0_r":[""],"item_7125_16530_0_0":[""],"item_7126_16523_0_0":["Sodium"],"item_7126_16524_0_0":[""],"item_7126_16525_0_0":[""],"item_7126_16525_0_0_r":[""],"item_7126_16526_0_0":[""],"item_7127_16519_0_0":["Potassium"],"item_7127_16520_0_0":[""],"item_7127_16521_0_0":[""],"item_7127_16521_0_0_r":[""],"item_7127_16522_0_0":[""],"item_7128_16515_0_0":["Chloride"],"item_7128_16516_0_0":[""],"item_7128_16517_0_0":[""],"item_7128_16517_0_0_r":[""],"item_7128_16518_0_0":[""],"item_7129_16511_0_0":["Creatinine"],"item_7129_16512_0_0":[""],"item_7129_16513_0_0":[""],"item_7129_16513_0_0_r":[""],"item_7129_16514_0_0":[""],"item_7130_16507_0_0":["BUN"],"item_7130_16508_0rl=/cs8635_sit_11_01/crf-submit/S4Z068/3015 , dataJson={"crfpage_type":["CRF"],"qst_rowno":["7148#0#0","7141#0#0","7143#0#0","7144#0#0","7145#0#0","7146#0#0","7147#0#0","7123#0#0","7125#0#0","7126#0#0","7127#0#0","7128#0#0","7129#0#0","7130#0#0","7131#0#0","7132#0#0","7133#0#0","7134#0#0","7135#0#0","7136#0#0","7137#0#0","7138#0#0","7139#0#0","7140#0#0","7117#0#0","7119#0#0","7120#0#0","7121#0#0","7122#0#0"],"item_7148_16445_0_0":[""],"_item_7141_16466_0_0":[""],"item_7143_16462_0_0":["RBC"],"item_7143_16463_0_0":[""],"item_7143_16464_0_0":[""],"item_7143_16464_0_0_r":[""],"item_7143_16465_0_0":[""],"item_7144_16458_0_0":["Hemoglobin"],"item_7144_16459_0_0":[""],"item_7144_16460_0_0":[""],"item_7144_16460_0_0_r":[""],"item_7144_16461_0_0":[""],"item_7145_16454_0_0":["Hematocrit"],"item_7145_16455_0_0":[""],"item_7145_16456_0_0":[""],"item_7145_16456_0_0_r":[""],"item_7145_16457_0_0":[""],"item_7146_16450_0_0":["Platelet"],"item_7146_16451_0_0":[""],"item_7146_16452_0_0":[""],"item_7146_16452_0_0_r":[""],"item_7146_16453_0_0":[""],"item_7147_16446_0_0":["WBC"],"item_7147_16447_0_0":[""],"item_7147_16448_0_0":[""],"item_7147_16448_0_0_r":[""],"item_7147_16449_0_0":[""],"_item_7123_16531_0_0":[""],"item_7125_16527_0_0":["Calcium"],"item_7125_16528_0_0":[""],"item_7125_16529_0_0":[""],"item_7125_16529_0_0_r":[""],"item_7125_16530_0_0":[""],"item_7126_16523_0_0":["Sodium"],"item_7126_16524_0_0":[""],"item_7126_16525_0_0":[""],"item_7126_16525_0_0_r":[""],"item_7126_16526_0_0":[""],"item_7127_16519_0_0":["Potassium"],"item_7127_16520_0_0":[""],"item_7127_16521_0_0":[""],"item_7127_16521_0_0_r":[""],"item_7127_16522_0_0":[""],"item_7128_16515_0_0":["Chloride"],"item_7128_16516_0_0":[""],"item_7128_16517_0_0":[""],"item_7128_16517_0_0_r":[""],"item_7128_16518_0_0":[""],"item_7129_16511_0_0":["Creatinine"],"item_7129_16512_0_0":[""],"item_7129_16513_0_0":[""],"item_7129_16513_0_0_r":[""],"item_7129_16514_0_0":[""],"item_7130_16507_0_0":["BUN"],"item_7130_16508_0rl=/cs8635_sit_11_01/crf-submit/S4Z068/3015 , dataJson={"crfpage_type":["CRF"],"qst_rowno":["7148#0#0","7141#0#0","7143#0#0","7144#0#0","7145#0#0","7146#0#0","7147#0#0","7123#0#0","7125#0#0","7126#0#0","7127#0#0","7128#0#0","7129#0#0","7130#0#0","7131#0#0","7132#0#0","7133#0#0","7134#0#0","7135#0#0","7136#0#0","7137#0#0","7138#0#0","7139#0#0","7140#0#0","7117#0#0","7119#0#0","7120#0#0","7121#0#0","7122#0#0"],"item_7148_16445_0_0":[""],"_item_7141_16466_0_0":[""],"item_7143_16462_0_0":["RBC"],"item_7143_16463_0_0":[""],"item_7143_16464_0_0":[""],"item_7143_16464_0_0_r":[""],"item_7143_16465_0_0":[""],"item_7144_16458_0_0":["Hemoglobin"],"item_7144_16459_0_0":[""],"item_7144_16460_0_0":[""],"item_7144_16460_0_0_r":[""],"item_7144_16461_0_0":[""],"item_7145_16454_0_0":["Hematocrit"],"item_7145_16455_0_0":[""],"item_7145_16456_0_0":[""],"item_7145_16456_0_0_r":[""],"item_7145_16457_0_0":[""],"item_7146_16450_0_0":["Platelet"],"item_7146_16451_0_0":[""],"item_7146_16452_0_0":[""],"item_7146_16452_0_0_r":[""],"item_7146_16453_0_0":[""],"item_7147_16446_0_0":["WBC"],"item_7147_16447_0_0":[""],"item_7147_16448_0_0":[""],"item_7147_16448_0_0_r":[""],"item_7147_16449_0_0":[""],"_item_7123_16531_0_0":[""],"item_7125_16527_0_0":["Calcium"],"item_7125_16528_0_0":[""],"item_7125_16529_0_0":[""],"item_7125_16529_0_0_r":[""],"item_7125_16530_0_0":[""],"item_7126_16523_0_0":["Sodium"],"item_7126_16524_0_0":[""],"item_7126_16525_0_0":[""],"item_7126_16525_0_0_r":[""],"item_7126_16526_0_0":[""],"item_7127_16519_0_0":["Potassium"],"item_7127_16520_0_0":[""],"item_7127_16521_0_0":[""],"item_7127_16521_0_0_r":[""],"item_7127_16522_0_0":[""],"item_7128_16515_0_0":["Chloride"],"item_7128_16516_0_0":[""],"item_7128_16517_0_0":[""],"item_7128_16517_0_0_r":[""],"item_7128_16518_0_0":[""],"item_7129_16511_0_0":["Creatinine"],"item_7129_16512_0_0":[""],"item_7129_16513_0_0":[""],"item_7129_16513_0_0_r":[""],"item_7129_16514_0_0":[""],"item_7130_16507_0_0":["BUN"],"item_7130_16508_03A[""],"item_7121_16536_0_0":["Protein"],"item_7121_16537_0_0":[""],"item_7121_16539_0_0":[""],"item_7122_16532_0_0":["Glucose"],"item_7122_16533_0_0":[""],"item_7122_16535_0_0":[""]}
> Received is:
> dataJson={"crfpage_type":["CRF"],"qst_rowno":["7148#0#0","7141#0#0","7143#0#0","7144#0#0","7145#0#0","7146#0#0","7147#0#0","7123#0#0","7125#0#0","7126#0#0","7127#0#0","7128#0#0","7129#0#0","7130#0#0","7131#0#0","7132#0#0","7133#0#0","7134#0#0","7135#0#0","7136#0#0","7137#0#0","7138#0#0","7139#0#0","7140#0#0","7117#0#0","7119#0#0","7120#0#0","7121#0#0","7122#0#0"],"item_7148_16445_0_0":[""],"_item_7141_16466_0_0":[""],"item_7143_16462_0_0":["RBC"],"item_7143_16463_0_0":[""],"item_7143_16464_0_0":[""],"item_7143_16464_0_0_r":[""],"item_7143_16465_0_0":[""],"item_7144_16458_0_0":["Hemoglobin"],"item_7144_16459_0_0":[""],"item_7144_16460_0_0":[""],"item_7144_16460_0_0_r":[""],"item_7144_16461_0_0":[""],"item_7145_16454_0_0":["Hematocrit"],"item_7145_16455_0_0":[""],"item_7145_16456_0_0":[""],"item_7145_16456_0_0_r":[""],"item_7145_16457_0_0":[""],"item_7146_16450_0_0":["Platelet"],"item_7146_16451_0_0":[""],"item_7146_16452_0_0":[""],"item_7146_16452_0_0_r":[""],"item_7146_16453_0_0":[""],"item_7147_16446_0_0":["WBC"],"item_7147_16447_0_0":[""],"item_7147_16448_0_0":[""],"item_7147_16448_0_0_r":[""],"item_7147_16449_0_0":[""],"_item_7123_16531_0_0":[""],"item_7125_16527_0_0":["Calcium"],"item_7125_16528_0_0":[""],"item_7125_16529_0_0":[""],"item_7125_16529_0_0_r":[""],"item_7125_16530_0_0":[""],"item_7126_16523_0_0":["Sodium"],"item_7126_16524_0_0":[""],"item_7126_16525_0_0":[""],"item_7126_16525_0_0_r":[""],"item_7126_16526_0_0":[""],"item_7127_16519_0_0":["Potassium"],"item_7127_16520_0_0":[""],"item_7127_16521_0_0":[""],"item_7127_16521_0_0_r":[""],"item_7127_16522_0_0":[""],"item_7128_16515_0_0":["Chloride"],"item_7128_16516_0_0":[""],"item_7128_16517_0_0":[""],"item_7128_16517_0_0_r":[""],"item_7128_16518_0_0":[""],"item_7129_16511_0_0":["Creatinine"],"item_7129_16512_0_0":[""],"item_7129_16513_0_0":[""],"item_7129_16513_0_0_r":[""],"item_7129_16514_0_0":[""],"item_7130_16507_0_0":["BUN"],"item_7130_16508_0rl=/cs8635_sit_11_01/crf-submit/S4Z068/3015 , dataJson={"crfpage_type":["CRF"],"qst_rowno":["7148#0#0","7141#0#0","7143#0#0","7144#0#0","7145#0#0","7146#0#0","7147#0#0","7123#0#0","7125#0#0","7126#0#0","7127#0#0","7128#0#0","7129#0#0","7130#0#0","7131#0#0","7132#0#0","7133#0#0","7134#0#0","7135#0#0","7136#0#0","7137#0#0","7138#0#0","7139#0#0","7140#0#0","7117#0#0","7119#0#0","7120#0#0","7121#0#0","7122#0#0"],"item_7148_16445_0_0":[""],"_item_7141_16466_0_0":[""],"item_7143_16462_0_0":["RBC"],"item_7143_16463_0_ataJson={"crfpage_type":["CRF"],"qst_rowno":["7148#0#0","7141#0#0","7143#0#0","7144#0#0","7145#0#0","7146#0#0","7147#0#0","7123#0#0","7125#0#0","7126#0#0","7127#0#0","7128#0#0","7129#0#0","7130#0#0","7131#0#0","7132#0#0","7133#0#0","7134#0#0","7135#0#0","7136#0#0","7137#0#0","7138#0#0","7139#0#0","7140#0#0","7117#0#0","7119#0#0","7120#0#0","7121#0#0","7122#0#0"],"item_7148_16445_0_0":[""],"_item_7141_16466_0_0":[""],"item_7143_16462_0_0":["RBC"],"item_7143_16463_0_0":[""],"item_7143_16464_0_0":[""],"item_7143_16464_0_0_r":[""],"item_7143_16465_0_0":[""],"item_7144_16458_0_0":["Hemoglobin"],"item_7144_16459_0_0":[""],"item_7144_16460_0_0":[""],"item_7144_16460_0_0_r":[""],"item_7144_16461_0_0":[""],"item_7145_16454_0_0":["Hematocrit"],"item_7145_16455_0_0":[""],"item_7145_16456_0_0":[""],"item_7145_16456_0_0_r":[""],"item_7145_16457_0_0":[""],"item_7146_16450_0_0":["Platelet"],"item_7146_16451_0_0":[""],"item_7146_16452_0_0":[""],"item_7146_16452_0_0_r":[""],"item_7146_16453_0_0":[""],"item_7147_16446_0_0":["WBC"],"item_7147_16447_0_0":[""],"item_7147_16448_0_0":[""],"item_7147_16448_0_0_r":[""],"item_7147_16449_0_0":[""],"_item_7123_16531_0_0":[""],"item_7125_16527_0_0":["Calcium"],"item_7125_16528_0_0":[""],"item_7125_16529_0_0":[""],"item_7125_16529_0_0_r":[""],"item_7125_16530_0_0":[""],"item_7126_16523_0_0":["Sodium"],"item_7126_16524_0_0":[""],"item_7126_16525_0_0":[""],"item_7126_16525_0_0_r":[""],"item_7126_16526_0_0":[""],"item_7127_16519_0_0":["Potassium"],"item_7127_16520_0_0":[""],"item_7127_16521_0_0":[""],"item_7127_16521_0_0_r":[""],"item_7127_16522_0_0":[""],"item_7128_16515_0_0":["Chloride"],"item_7128_16516_0_0":[""],"item_7128_16517_0_0":[""],"item_7128_16517_0_0_r":[""],"item_7128_16518_0_0":[""],"item_7129_16511_0_0":["Creatinine"],"item_7129_16512_0_0":[""],"item_7129_16513_0_0":[""],"item_7129_16513_0_0_r":[""],"item_7129_16514_0_0":[""],"item_7130_16507_0_0":["BUN"],"item_7130_16508_0rl=/cs8635_sit_11_01/crf-submit/S4Z068/3015 , dataJson={"crfpage_type":["CRF"],"qst_rowno":["7148#0#0","7141#0#0","7143#0#0","7144#0#0","7145#0#0","7146#0#0","7147#0#0","7123#0#0","7125#0#0","7126#0#0","7127#0#0","7128#0#0","7129#0#0","7130#0#0","7131#0#0","7132#0#0","7133#0#0","7134#0#0","7135#0#0","7136#0#0","7137#0#0","7138#0#0","7139#0#0","7140#0#0","7117#0#0","7119#0#0","7120#0#0","7121#0#0","7122#0#0"],"item_7148_16445_0_0":[""],"_item_7141_16466_0_0":[""],"item_7143_16462_0_0":["RBC"],"item_7143_16463_0_
> I test use HTTP Connector same case, but it is normal(request and received is same)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (WFLY-4413) Network connection leak in asynchronous servlet
by Ron Peng (JIRA)
[ https://issues.jboss.org/browse/WFLY-4413?page=com.atlassian.jira.plugin.... ]
Ron Peng commented on WFLY-4413:
--------------------------------
Maybe when end the request, some exceptions are thrown, the operation "attempt to read again" is missed.
> Network connection leak in asynchronous servlet
> -----------------------------------------------
>
> Key: WFLY-4413
> URL: https://issues.jboss.org/browse/WFLY-4413
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Environment: Linux
> Reporter: jeremy_lv lv
> Assignee: Stuart Douglas
> Priority: Blocker
> Labels: undertow
>
> {panel:title=Phenomenon|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
> When the connection is suddenly terminated during the period we access the asynchronous servlet application, the connection will be leaked. However, the connection won't be leak when we access the synchronous servlet application.
> {panel}
> *Some of the stacktrace are as follows:*
> {panel:title=Stacktrace|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
> 14:34:23,751 ERROR [io.undertow.request] (default task-22) Blocking request fail
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpSer
> at io.undertow.servlet.spec.AsyncContextImpl$3.run(AsyncContextImpl.java
> at io.undertow.servlet.spec.AsyncContextImpl$6.run(AsyncContextImpl.java
> at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(As
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.io.IOException: Connection reset by peer
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_25]
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:94) [rt.jar:1.7.0
> at sun.nio.ch.IOUtil.write(IOUtil.java:51) [rt.jar:1.7.0_25]
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:466) [rt.ja
> at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150)
> at io.undertow.server.protocol.http.HttpResponseConduit.processWrite(Htt
> at io.undertow.server.protocol.http.HttpResponseConduit.flush(HttpRespon
> at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(Abstr
> at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkCha
> at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStre
> at org.xnio.channels.Channels.flushBlocking(Channels.java:63)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputS
> at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpSer
> ... 6 more
> {panel}
> *Here's the test war code you can used to reproduce this phenomenon:*
> {code:title=AsyncDemoServlet.java|borderStyle=solid}
> import java.io.IOException;
> import javax.servlet.AsyncContext;
> import javax.servlet.ServletException;
> import javax.servlet.annotation.WebServlet;
> import javax.servlet.http.HttpServlet;
> import javax.servlet.http.HttpServletRequest;
> import javax.servlet.http.HttpServletResponse;
> @WebServlet(urlPatterns="/asyncDemoServlet",asyncSupported=true)
> public class AsyncDemoServlet extends HttpServlet {
> private static final long serialVersionUID = 1L;
> protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
> response.setContentType("text/html;charset=UTF-8");
> //Execute the business logic in sub-thread.
> AsyncContext ctx = request.startAsync();
> new Thread(new Executor(ctx)).start();
> }
> protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
> doGet(request, response);
> }
> public class Executor implements Runnable {
> private AsyncContext ctx = null;
> public Executor(AsyncContext ctx){
> this.ctx = ctx;
> }
> public void run(){
> try {
> //wait for 5 seconds to simulate the business logic.
> Thread.sleep(5000);
> ctx.complete();
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months