[JBoss JIRA] (MODCLUSTER-386) Support for multiple different session cookie/path names
by Radoslav Husar (JIRA)
Radoslav Husar created MODCLUSTER-386:
-----------------------------------------
Summary: Support for multiple different session cookie/path names
Key: MODCLUSTER-386
URL: https://issues.jboss.org/browse/MODCLUSTER-386
Project: mod_cluster
Issue Type: Feature Request
Affects Versions: 1.3.0.Alpha2
Reporter: Radoslav Husar
Assignee: Jean-Frederic Clere
With Undertow, web applications can now bring in their own session cookie configuration and be different per application. Mod_cluster currently supports only 1 unique cookie name for all.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (MODCLUSTER-284) remove_session_route doesn't work as expected with session id in the URL
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-284?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-284:
--------------------------------------
Description:
Looking at the code of remove_session_route (and trying it) i saw that URLs lke this one
/test.jsp;jsessionid=1233454532432342.NODE01
/test.jsp;jsessionid=1233454532432342.NODE01?p1=v1&p2=v2
/test.jsp;jsessionid=1233454532432342.NODE01;otherparam=value
are not correctly parsed and the session id is not removed.
To note that it seems the code handles jsessionid as url parameter and not as URL "path parameter" (see for isntance http://doriantaylor.com/policy/http-url-path-parameter-syntax).
This is for instance a piece of tomcat code that does something like what remove_session_route should do (at least in the URL part):
{code}
/**
* Strips a servlet session ID from <tt>url</tt>. The session ID
* is encoded as a URL "path parameter" beginning with "jsessionid=".
* We thus remove anything we find between ";jsessionid=" (inclusive)
* and either EOS or a subsequent ';' (exclusive).
*
* taken from org.apache.taglibs.standard.tag.common.core.ImportSupport
*/
public static String stripSession(String url) {
StringBuffer u = new StringBuffer(url);
int sessionStart;
while ((sessionStart = u.toString().indexOf(";jsessionid=")) != -1) {
int sessionEnd = u.toString().indexOf(";", sessionStart + 1);
if (sessionEnd == -1)
sessionEnd = u.toString().indexOf("?", sessionStart + 1);
if (sessionEnd == -1) // still
sessionEnd = u.length();
u.delete(sessionStart, sessionEnd);
}
return u.toString();
}
{code}
was:
Looking at the code of remove_session_route (and trying it) i saw that URLs lke this one
/test.jsp;jsessionid=1233454532432342.NODE01
/test.jsp;jsessionid=1233454532432342.NODE01?p1=v1&p2=v2
/test.jsp;jsessionid=1233454532432342.NODE01;otherparam=value
are not correctly parsed and the session id is not removed.
To note that it seems the code handles jsessionid as url parameter and not as URL "path parameter" (see for isntance http://doriantaylor.com/policy/http-url-path-parameter-syntax).
This is for instance a piece of tomcat code that does something like what remove_session_route should do (at least in the URL part):
/**
* Strips a servlet session ID from <tt>url</tt>. The session ID
* is encoded as a URL "path parameter" beginning with "jsessionid=".
* We thus remove anything we find between ";jsessionid=" (inclusive)
* and either EOS or a subsequent ';' (exclusive).
*
* taken from org.apache.taglibs.standard.tag.common.core.ImportSupport
*/
public static String stripSession(String url) {
StringBuffer u = new StringBuffer(url);
int sessionStart;
while ((sessionStart = u.toString().indexOf(";jsessionid=")) != -1) {
int sessionEnd = u.toString().indexOf(";", sessionStart + 1);
if (sessionEnd == -1)
sessionEnd = u.toString().indexOf("?", sessionStart + 1);
if (sessionEnd == -1) // still
sessionEnd = u.length();
u.delete(sessionStart, sessionEnd);
}
return u.toString();
}
> remove_session_route doesn't work as expected with session id in the URL
> ------------------------------------------------------------------------
>
> Key: MODCLUSTER-284
> URL: https://issues.jboss.org/browse/MODCLUSTER-284
> Project: mod_cluster
> Issue Type: Bug
> Affects Versions: 1.1.3.Final, 1.2.0.Final
> Reporter: Stefano Nichele
> Assignee: Jean-Frederic Clere
>
> Looking at the code of remove_session_route (and trying it) i saw that URLs lke this one
> /test.jsp;jsessionid=1233454532432342.NODE01
> /test.jsp;jsessionid=1233454532432342.NODE01?p1=v1&p2=v2
> /test.jsp;jsessionid=1233454532432342.NODE01;otherparam=value
> are not correctly parsed and the session id is not removed.
> To note that it seems the code handles jsessionid as url parameter and not as URL "path parameter" (see for isntance http://doriantaylor.com/policy/http-url-path-parameter-syntax).
> This is for instance a piece of tomcat code that does something like what remove_session_route should do (at least in the URL part):
> {code}
> /**
> * Strips a servlet session ID from <tt>url</tt>. The session ID
> * is encoded as a URL "path parameter" beginning with "jsessionid=".
> * We thus remove anything we find between ";jsessionid=" (inclusive)
> * and either EOS or a subsequent ';' (exclusive).
> *
> * taken from org.apache.taglibs.standard.tag.common.core.ImportSupport
> */
> public static String stripSession(String url) {
> StringBuffer u = new StringBuffer(url);
> int sessionStart;
> while ((sessionStart = u.toString().indexOf(";jsessionid=")) != -1) {
> int sessionEnd = u.toString().indexOf(";", sessionStart + 1);
> if (sessionEnd == -1)
> sessionEnd = u.toString().indexOf("?", sessionStart + 1);
> if (sessionEnd == -1) // still
> sessionEnd = u.length();
> u.delete(sessionStart, sessionEnd);
> }
> return u.toString();
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (MODCLUSTER-284) remove_session_route doesn't work as expected with session id in the URL
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-284?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-284:
--------------------------------------
Fix Version/s: (was: 1.2.1.Final)
> remove_session_route doesn't work as expected with session id in the URL
> ------------------------------------------------------------------------
>
> Key: MODCLUSTER-284
> URL: https://issues.jboss.org/browse/MODCLUSTER-284
> Project: mod_cluster
> Issue Type: Bug
> Affects Versions: 1.1.3.Final, 1.2.0.Final
> Reporter: Stefano Nichele
> Assignee: Jean-Frederic Clere
>
> Looking at the code of remove_session_route (and trying it) i saw that URLs lke this one
> /test.jsp;jsessionid=1233454532432342.NODE01
> /test.jsp;jsessionid=1233454532432342.NODE01?p1=v1&p2=v2
> /test.jsp;jsessionid=1233454532432342.NODE01;otherparam=value
> are not correctly parsed and the session id is not removed.
> To note that it seems the code handles jsessionid as url parameter and not as URL "path parameter" (see for isntance http://doriantaylor.com/policy/http-url-path-parameter-syntax).
> This is for instance a piece of tomcat code that does something like what remove_session_route should do (at least in the URL part):
> /**
> * Strips a servlet session ID from <tt>url</tt>. The session ID
> * is encoded as a URL "path parameter" beginning with "jsessionid=".
> * We thus remove anything we find between ";jsessionid=" (inclusive)
> * and either EOS or a subsequent ';' (exclusive).
> *
> * taken from org.apache.taglibs.standard.tag.common.core.ImportSupport
> */
> public static String stripSession(String url) {
> StringBuffer u = new StringBuffer(url);
> int sessionStart;
> while ((sessionStart = u.toString().indexOf(";jsessionid=")) != -1) {
> int sessionEnd = u.toString().indexOf(";", sessionStart + 1);
> if (sessionEnd == -1)
> sessionEnd = u.toString().indexOf("?", sessionStart + 1);
> if (sessionEnd == -1) // still
> sessionEnd = u.length();
> u.delete(sessionStart, sessionEnd);
> }
> return u.toString();
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (MODCLUSTER-384) mod_cluster with Undertow throws java.lang.IllegalArgumentException on IPv6 system
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-384?page=com.atlassian.jira.pl... ]
Radoslav Husar commented on MODCLUSTER-384:
-------------------------------------------
I tried to reproduce a similar setup on my machine and couldn't get it to fail. Everything worked fine.
> mod_cluster with Undertow throws java.lang.IllegalArgumentException on IPv6 system
> ----------------------------------------------------------------------------------
>
> Key: MODCLUSTER-384
> URL: https://issues.jboss.org/browse/MODCLUSTER-384
> Project: mod_cluster
> Issue Type: Bug
> Affects Versions: 1.3.0.Alpha2
> Environment: both Oracle JDK7 and OpenJDK7, RHEL6, both pure-IPv6 and dualstack
> Reporter: Michal Babacek
> Assignee: Michal Babacek
> Attachments: error_log.zip, jboss-eap-8.0-2.server.log.zip, jboss-eap-8.0.server.log.zip
>
>
> Guys, something is amiss with MCMP parsing and/or Undertow integration on IPv6 systems.
> There is this test:
> # configure and start *balancer*:httpd, *worker1*:jboss-eap-8.0, *worker2*:jboss-eap-8.0-2 (ignore this weird `jboss-eap-8`, it's just WildFly 8.0.0.Final-SNAPSHOT)
> # verify that application context is accessible via balancer
> # make a request and remember which worker processed it
> # commence a clean shutdown on that worker
> # make another request and make sure the other worker takes care of it
> # start that worker stopped in step 4.
> # wait till it's present on the mod_cluster manager console
> # stop that other worker that handled the request in step 5.
> # make a request and verify that someone is gonna take care of it
> The aforementioned test {color:green}passes{color} with the exactly same bits in an IPv4 environment with no problems whatsoever.
> On an IPv6 system, setup collapses with this in the server log (attached server log for both workers: [^jboss-eap-8.0.server.log.zip], [^jboss-eap-8.0-2.server.log.zip] )
> {noformat}
> 2014-01-30 09:00:41,279 ERROR [org.jboss.modcluster] (UndertowEventHandlerAdapter - 1) MODCLUSTER000042: Error MEM sending CONFIG command to 2620:52:0:105f:0:0:ffff:6d/2620:52:0:105f:0:0:ffff:6d:8847, configuration will be reset: MEM: Old node still exist
> 2014-01-30 09:00:41,286 ERROR [org.jboss.modcluster] (UndertowEventHandlerAdapter - 1) MODCLUSTER000042: Error MEM sending CONFIG command to 2620:52:0:105f:0:0:ffff:23/2620:52:0:105f:0:0:ffff:23:8847, configuration will be reset: MEM: Old node still exist
> 2014-01-30 09:00:51,308 ERROR [org.jboss.modcluster] (UndertowEventHandlerAdapter - 1) MODCLUSTER000042: Error MEM sending CONFIG command to 2620:52:0:105f:0:0:ffff:2b/2620:52:0:105f:0:0:ffff:2b:8847, configuration will be reset: MEM: Old node still exist
> 2014-01-30 09:01:01,332 ERROR [org.jboss.modcluster] (UndertowEventHandlerAdapter - 1) MODCLUSTER000042: Error MEM sending CONFIG command to 2620:52:0:105f:0:0:ffff:1/2620:52:0:105f:0:0:ffff:1:8847, configuration will be reset: MEM: Old node still exist
> 2014-01-30 09:01:01,338 ERROR [org.jboss.modcluster] (UndertowEventHandlerAdapter - 1) MODCLUSTER000042: Error MEM sending STATUS command to 2620:52:0:105f:0:0:ffff:6d/2620:52:0:105f:0:0:ffff:6d:8847, configuration will be reset: MEM: Can't read node
> 2014-01-30 09:01:01,341 ERROR [org.jboss.modcluster] (UndertowEventHandlerAdapter - 1) MODCLUSTER000042: Error MEM sending STATUS command to 2620:52:0:105f:0:0:ffff:23/2620:52:0:105f:0:0:ffff:23:8847, configuration will be reset: MEM: Can't read node
> 2014-01-30 09:01:11,350 ERROR [org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter] (UndertowEventHandlerAdapter - 1) Node: [1],Name: jboss-eap-8.0-2,Balancer: qacluster,LBGroup: ,Host: [2620:52:0:105f:0:0:ffff:6d],Port: 8110,Type: ajp,Flushpackets: Off,Flushwait: 10,Ping: 10,Smax: 1,Ttl: 60,Elected: 8,Read: 544,Transfered: 0,Connected: 0,Load: 100
> Node: [3],Name: REMOVED,Balancer: qacluster,LBGroup: ,Host: [2620:52:0:105f:0:0:ffff:6d],Port: 8009,Type: ajp,Flushpackets: Off,Flushwait: 10,Ping: 10,Smax: 1,Ttl: 60,Elected: 5,Read: 340,Transfered: 0,Connected: 0,Load: 100
> Vhost: [2:1:1], Alias: localhost
> Vhost: [2:1:2], Alias: default-host
> Vhost: [3:1:3], Alias: default-host
> Vhost: [3:1:4], Alias: localhost
> Vhost: [1:1:5], Alias: default-host
> Vhost: [1:1:6], Alias: localhost
> Context: [2:1:1], Context: /clusterbench, Status: ENABLED
> Context: [3:1:2], Context: /clusterbench, Status: ENABLED
> Context: [1:1:3], Context: /clusterbench, Status: ENABLED
> : java.lang.IllegalArgumentException: Node: [1],Name: jboss-eap-8.0-2,Balancer: qacluster,LBGroup: ,Host: [2620:52:0:105f:0:0:ffff:6d],Port: 8110,Type: ajp,Flushpackets: Off,Flushwait: 10,Ping: 10,Smax: 1,Ttl: 60,Elected: 8,Read: 544,Transfered: 0,Connected: 0,Load: 100
> Node: [3],Name: REMOVED,Balancer: qacluster,LBGroup: ,Host: [2620:52:0:105f:0:0:ffff:6d],Port: 8009,Type: ajp,Flushpackets: Off,Flushwait: 10,Ping: 10,Smax: 1,Ttl: 60,Elected: 5,Read: 340,Transfered: 0,Connected: 0,Load: 100
> Vhost: [2:1:1], Alias: localhost
> Vhost: [2:1:2], Alias: default-host
> Vhost: [3:1:3], Alias: default-host
> Vhost: [3:1:4], Alias: localhost
> Vhost: [1:1:5], Alias: default-host
> Vhost: [1:1:6], Alias: localhost
> Context: [2:1:1], Context: /clusterbench, Status: ENABLED
> Context: [3:1:2], Context: /clusterbench, Status: ENABLED
> Context: [1:1:3], Context: /clusterbench, Status: ENABLED
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPResponseParser.parseInfoResponse(DefaultMCMPResponseParser.java:96) [mod_cluster-core-1.3.0.Alpha2-SNAPSHOT.jar:1.3.0.Alpha2-SNAPSHOT]
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:381) [mod_cluster-core-1.3.0.Alpha2-SNAPSHOT.jar:1.3.0.Alpha2-SNAPSHOT]
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:350) [mod_cluster-core-1.3.0.Alpha2-SNAPSHOT.jar:1.3.0.Alpha2-SNAPSHOT]
> at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:458) [mod_cluster-core-1.3.0.Alpha2-SNAPSHOT.jar:1.3.0.Alpha2-SNAPSHOT]
> at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.run(UndertowEventHandlerAdapter.java:160) [wildfly-mod_cluster-undertow-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_45]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) [rt.jar:1.7.0_45]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_45]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {noformat}
> WDYT?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (MODCLUSTER-384) mod_cluster with Undertow throws java.lang.IllegalArgumentException on IPv6 system
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-384?page=com.atlassian.jira.pl... ]
Michal Babacek reassigned MODCLUSTER-384:
-----------------------------------------
Assignee: Michal Babacek (was: Radoslav Husar)
I'm assigning this "issue" to myself for further investigation. At the moment, it looks like an environment issue, because in some IPv6 environments, the test actually passes just fine. I'll close this JIRA as soon as I have an explanation.
> mod_cluster with Undertow throws java.lang.IllegalArgumentException on IPv6 system
> ----------------------------------------------------------------------------------
>
> Key: MODCLUSTER-384
> URL: https://issues.jboss.org/browse/MODCLUSTER-384
> Project: mod_cluster
> Issue Type: Bug
> Affects Versions: 1.3.0.Alpha2
> Environment: both Oracle JDK7 and OpenJDK7, RHEL6, both pure-IPv6 and dualstack
> Reporter: Michal Babacek
> Assignee: Michal Babacek
> Attachments: error_log.zip, jboss-eap-8.0-2.server.log.zip, jboss-eap-8.0.server.log.zip
>
>
> Guys, something is amiss with MCMP parsing and/or Undertow integration on IPv6 systems.
> There is this test:
> # configure and start *balancer*:httpd, *worker1*:jboss-eap-8.0, *worker2*:jboss-eap-8.0-2 (ignore this weird `jboss-eap-8`, it's just WildFly 8.0.0.Final-SNAPSHOT)
> # verify that application context is accessible via balancer
> # make a request and remember which worker processed it
> # commence a clean shutdown on that worker
> # make another request and make sure the other worker takes care of it
> # start that worker stopped in step 4.
> # wait till it's present on the mod_cluster manager console
> # stop that other worker that handled the request in step 5.
> # make a request and verify that someone is gonna take care of it
> The aforementioned test {color:green}passes{color} with the exactly same bits in an IPv4 environment with no problems whatsoever.
> On an IPv6 system, setup collapses with this in the server log (attached server log for both workers: [^jboss-eap-8.0.server.log.zip], [^jboss-eap-8.0-2.server.log.zip] )
> {noformat}
> 2014-01-30 09:00:41,279 ERROR [org.jboss.modcluster] (UndertowEventHandlerAdapter - 1) MODCLUSTER000042: Error MEM sending CONFIG command to 2620:52:0:105f:0:0:ffff:6d/2620:52:0:105f:0:0:ffff:6d:8847, configuration will be reset: MEM: Old node still exist
> 2014-01-30 09:00:41,286 ERROR [org.jboss.modcluster] (UndertowEventHandlerAdapter - 1) MODCLUSTER000042: Error MEM sending CONFIG command to 2620:52:0:105f:0:0:ffff:23/2620:52:0:105f:0:0:ffff:23:8847, configuration will be reset: MEM: Old node still exist
> 2014-01-30 09:00:51,308 ERROR [org.jboss.modcluster] (UndertowEventHandlerAdapter - 1) MODCLUSTER000042: Error MEM sending CONFIG command to 2620:52:0:105f:0:0:ffff:2b/2620:52:0:105f:0:0:ffff:2b:8847, configuration will be reset: MEM: Old node still exist
> 2014-01-30 09:01:01,332 ERROR [org.jboss.modcluster] (UndertowEventHandlerAdapter - 1) MODCLUSTER000042: Error MEM sending CONFIG command to 2620:52:0:105f:0:0:ffff:1/2620:52:0:105f:0:0:ffff:1:8847, configuration will be reset: MEM: Old node still exist
> 2014-01-30 09:01:01,338 ERROR [org.jboss.modcluster] (UndertowEventHandlerAdapter - 1) MODCLUSTER000042: Error MEM sending STATUS command to 2620:52:0:105f:0:0:ffff:6d/2620:52:0:105f:0:0:ffff:6d:8847, configuration will be reset: MEM: Can't read node
> 2014-01-30 09:01:01,341 ERROR [org.jboss.modcluster] (UndertowEventHandlerAdapter - 1) MODCLUSTER000042: Error MEM sending STATUS command to 2620:52:0:105f:0:0:ffff:23/2620:52:0:105f:0:0:ffff:23:8847, configuration will be reset: MEM: Can't read node
> 2014-01-30 09:01:11,350 ERROR [org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter] (UndertowEventHandlerAdapter - 1) Node: [1],Name: jboss-eap-8.0-2,Balancer: qacluster,LBGroup: ,Host: [2620:52:0:105f:0:0:ffff:6d],Port: 8110,Type: ajp,Flushpackets: Off,Flushwait: 10,Ping: 10,Smax: 1,Ttl: 60,Elected: 8,Read: 544,Transfered: 0,Connected: 0,Load: 100
> Node: [3],Name: REMOVED,Balancer: qacluster,LBGroup: ,Host: [2620:52:0:105f:0:0:ffff:6d],Port: 8009,Type: ajp,Flushpackets: Off,Flushwait: 10,Ping: 10,Smax: 1,Ttl: 60,Elected: 5,Read: 340,Transfered: 0,Connected: 0,Load: 100
> Vhost: [2:1:1], Alias: localhost
> Vhost: [2:1:2], Alias: default-host
> Vhost: [3:1:3], Alias: default-host
> Vhost: [3:1:4], Alias: localhost
> Vhost: [1:1:5], Alias: default-host
> Vhost: [1:1:6], Alias: localhost
> Context: [2:1:1], Context: /clusterbench, Status: ENABLED
> Context: [3:1:2], Context: /clusterbench, Status: ENABLED
> Context: [1:1:3], Context: /clusterbench, Status: ENABLED
> : java.lang.IllegalArgumentException: Node: [1],Name: jboss-eap-8.0-2,Balancer: qacluster,LBGroup: ,Host: [2620:52:0:105f:0:0:ffff:6d],Port: 8110,Type: ajp,Flushpackets: Off,Flushwait: 10,Ping: 10,Smax: 1,Ttl: 60,Elected: 8,Read: 544,Transfered: 0,Connected: 0,Load: 100
> Node: [3],Name: REMOVED,Balancer: qacluster,LBGroup: ,Host: [2620:52:0:105f:0:0:ffff:6d],Port: 8009,Type: ajp,Flushpackets: Off,Flushwait: 10,Ping: 10,Smax: 1,Ttl: 60,Elected: 5,Read: 340,Transfered: 0,Connected: 0,Load: 100
> Vhost: [2:1:1], Alias: localhost
> Vhost: [2:1:2], Alias: default-host
> Vhost: [3:1:3], Alias: default-host
> Vhost: [3:1:4], Alias: localhost
> Vhost: [1:1:5], Alias: default-host
> Vhost: [1:1:6], Alias: localhost
> Context: [2:1:1], Context: /clusterbench, Status: ENABLED
> Context: [3:1:2], Context: /clusterbench, Status: ENABLED
> Context: [1:1:3], Context: /clusterbench, Status: ENABLED
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPResponseParser.parseInfoResponse(DefaultMCMPResponseParser.java:96) [mod_cluster-core-1.3.0.Alpha2-SNAPSHOT.jar:1.3.0.Alpha2-SNAPSHOT]
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:381) [mod_cluster-core-1.3.0.Alpha2-SNAPSHOT.jar:1.3.0.Alpha2-SNAPSHOT]
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:350) [mod_cluster-core-1.3.0.Alpha2-SNAPSHOT.jar:1.3.0.Alpha2-SNAPSHOT]
> at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:458) [mod_cluster-core-1.3.0.Alpha2-SNAPSHOT.jar:1.3.0.Alpha2-SNAPSHOT]
> at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.run(UndertowEventHandlerAdapter.java:160) [wildfly-mod_cluster-undertow-8.0.0.Final-SNAPSHOT.jar:8.0.0.Final-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_45]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) [rt.jar:1.7.0_45]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_45]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {noformat}
> WDYT?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (MODCLUSTER-385) "MODCLUSTER000033: Failed to interrupt socket reception.: java.io.IOException: Invalid argument" on shutdown with IPv6
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-385?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-385:
--------------------------------------
Issue Type: Bug (was: Feature Request)
> "MODCLUSTER000033: Failed to interrupt socket reception.: java.io.IOException: Invalid argument" on shutdown with IPv6
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: MODCLUSTER-385
> URL: https://issues.jboss.org/browse/MODCLUSTER-385
> Project: mod_cluster
> Issue Type: Bug
> Affects Versions: 1.3.0.Alpha1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
>
> If -Djava.net.preferIPv4Stack=false, but mcast address is IPv4, shutting down the server results in exception:
> {noformat}
> 13:24:49,398 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.0.Final-SNAPSHOT "WildFly" started in 7860ms - Started 654 of 757 services (210 services are lazy, passive or on-demand)
> ^C13:24:57,591 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 14) MODCLUSTER000002: Initiating mod_cluster shutdown
> 13:24:57,591 WARN [org.jboss.modcluster] (ServerService Thread Pool -- 14) MODCLUSTER000033: Failed to interrupt socket reception.: java.io.IOException: Invalid argument
> at java.net.PlainDatagramSocketImpl.send(Native Method) [rt.jar:1.7.0_51]
> at java.net.DatagramSocket.send(DatagramSocket.java:676) [rt.jar:1.7.0_51]
> at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.interruptDatagramReader(AdvertiseListenerImpl.java:209)
> at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.stop(AdvertiseListenerImpl.java:228)
> at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.destroy(AdvertiseListenerImpl.java:244)
> at org.jboss.modcluster.ModClusterService.shutdown(ModClusterService.java:220)
> at org.wildfly.extension.mod_cluster.ContainerEventHandlerService.stop(ContainerEventHandlerService.java:115)
> at org.jboss.as.clustering.msc.AsynchronousService$2.run(AsynchronousService.java:114)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> 13:24:57,594 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS017535: Unregister web context: /clusterbench-passivating
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (MODCLUSTER-385) "MODCLUSTER000033: Failed to interrupt socket reception.: java.io.IOException: Invalid argument" on shutdown with IPv6
by Radoslav Husar (JIRA)
Radoslav Husar created MODCLUSTER-385:
-----------------------------------------
Summary: "MODCLUSTER000033: Failed to interrupt socket reception.: java.io.IOException: Invalid argument" on shutdown with IPv6
Key: MODCLUSTER-385
URL: https://issues.jboss.org/browse/MODCLUSTER-385
Project: mod_cluster
Issue Type: Feature Request
Affects Versions: 1.3.0.Alpha1
Reporter: Radoslav Husar
Assignee: Radoslav Husar
Priority: Minor
If -Djava.net.preferIPv4Stack=false, but mcast address is IPv4, shutting down the server results in exception:
{noformat}
13:24:49,398 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.0.Final-SNAPSHOT "WildFly" started in 7860ms - Started 654 of 757 services (210 services are lazy, passive or on-demand)
^C13:24:57,591 INFO [org.jboss.modcluster] (ServerService Thread Pool -- 14) MODCLUSTER000002: Initiating mod_cluster shutdown
13:24:57,591 WARN [org.jboss.modcluster] (ServerService Thread Pool -- 14) MODCLUSTER000033: Failed to interrupt socket reception.: java.io.IOException: Invalid argument
at java.net.PlainDatagramSocketImpl.send(Native Method) [rt.jar:1.7.0_51]
at java.net.DatagramSocket.send(DatagramSocket.java:676) [rt.jar:1.7.0_51]
at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.interruptDatagramReader(AdvertiseListenerImpl.java:209)
at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.stop(AdvertiseListenerImpl.java:228)
at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.destroy(AdvertiseListenerImpl.java:244)
at org.jboss.modcluster.ModClusterService.shutdown(ModClusterService.java:220)
at org.wildfly.extension.mod_cluster.ContainerEventHandlerService.stop(ContainerEventHandlerService.java:115)
at org.jboss.as.clustering.msc.AsynchronousService$2.run(AsynchronousService.java:114)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
13:24:57,594 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS017535: Unregister web context: /clusterbench-passivating
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months
[JBoss JIRA] (MODCLUSTER-383) Session draining broken: requests counting broken on load-balancer
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-383?page=com.atlassian.jira.pl... ]
Radoslav Husar commented on MODCLUSTER-383:
-------------------------------------------
I have verified the fix, it works for contexts.
I also noticed that other 2 values are wrong for the node:
{noformat}Balancer: mycluster,LBGroup: ,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 2,Ttl: 60000000,Status: OK,Elected: 297148,Read: 0,Transferred: 0,Connected: 5,Load: 74{noformat}
Namely: elected is at 297,148 even though the test sent 300,000 requets precisely. Connected is at 5, even though the server is down and all clients are off. Should we be worried about these too?
> Session draining broken: requests counting broken on load-balancer
> ------------------------------------------------------------------
>
> Key: MODCLUSTER-383
> URL: https://issues.jboss.org/browse/MODCLUSTER-383
> Project: mod_cluster
> Issue Type: Bug
> Affects Versions: 1.3.0.Alpha1
> Environment: Fedora 20, 64 bit, httpd 2.4.6 + mod_cluster master (21ceed3c219fc3ad743b361cafd1097ebac19dfe)
> Reporter: Radoslav Husar
> Assignee: Jean-Frederic Clere
> Priority: Critical
> Fix For: 1.3.0.Alpha2
>
>
> The request counting is broken. Looks like synchronization problem with dirty cached reads.
> Steps to reproduce:
> # start AS with some context
> # start LB
> # start 2 or more load driver threads
> # number of requests on that context goes to higher values than 2, eventually and slowly increasing
> On the AS it manifests as:
> {noformat}
> 19:44:14,160 WARN [org.jboss.modcluster] (MSC service thread 1-7) MODCLUSTER000022: Failed to drain 57 remaining pending requests from default-host:/clusterbench within 10.0 seconds
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 2 months