[JBoss JIRA] (WFLY-6486) Standalone JMS client of 2 node colocated live/backup symmetrical cluster fails to failover.
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6486?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-6486:
-----------------------------------
This looks an environmental issue.
It looks like the client can not reach the backup server on 192.168.99.102. Is there a network from the client to this server?
> Standalone JMS client of 2 node colocated live/backup symmetrical cluster fails to failover.
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-6486
> URL: https://issues.jboss.org/browse/WFLY-6486
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Environment: 2 node symmetrical colocated live/backup cluster (domain mode). Configuration (domain.xml, host-master.xml, host-slave.xml) provided as attachment.
> Reporter: Michal Sudra
> Assignee: Jeff Mesnil
> Attachments: client.log, domain.xml, host-master.xml, host-slave.xml, JmsClusterFailoverTest.java, master.log, slave.log
>
>
> There are two WildFly 10.0.0.Final servers configured in colocated replication topology running in domain mode and a standalone JMS client connected.
> When I kill one of my Wildfly instance, I can see in the logs that the backup server becomes live in the second server. But the client receives this error :
> {noformat}
> 2016-04-04 16:32:45,417 DEBUG [org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1] (Remoting "config-based-naming-client-endpoint" task-9) Channel end notification received, closing channel Channel ID 8baa48f5 (outbound) of Remoting connection 75986426 to /192.168.99.102:8080
> 2016-04-04 16:32:45,456 DEBUG [org.apache.activemq.artemis.core.client] (Thread-6 (ActiveMQ-client-global-threads-1863167529)) Trying reconnection attempt 0/-1
> 2016-04-04 16:32:45,457 DEBUG [org.apache.activemq.artemis.core.client] (Thread-6 (ActiveMQ-client-global-threads-1863167529)) Trying to connect with connector = org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnectorFactory@64f6106c, parameters = {httpUpgradeEnabled=true, port=8080, httpPpgradeEndpoint=http-acceptor, host=192.168.99.102} connector = null
> 2016-04-04 16:32:45,458 DEBUG [org.apache.activemq.artemis.core.client] (Thread-6 (ActiveMQ-client-global-threads-1863167529)) Started Netty Connector version 4.0.30.Final
> 2016-04-04 16:32:45,458 DEBUG [org.apache.activemq.artemis.core.client] (Thread-6 (ActiveMQ-client-global-threads-1863167529)) Remote destination: /192.168.99.102:8080
> 2016-04-04 16:32:46,474 ERROR [org.apache.activemq.artemis.core.client] (Thread-6 (ActiveMQ-client-global-threads-1863167529)) AMQ214016: Failed to create netty connection
> java.net.SocketException: Network is unreachable: no further information: /192.168.99.102:8080
> at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
> at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
> at io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:224)
> at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:289)
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:528)
> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
> at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354)
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:110)
> at java.lang.Thread.run(Thread.java:745)
> 2016-04-04 16:32:46,478 DEBUG [org.apache.activemq.artemis.core.client] (Thread-6 (ActiveMQ-client-global-threads-1863167529)) Connector towards NettyConnector [host=192.168.99.102, port=8080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true] failed
> 2016-04-04 16:32:46,480 DEBUG [org.apache.activemq.artemis.core.client] (Thread-6 (ActiveMQ-client-global-threads-1863167529)) Trying backup config = TransportConfiguration(name=http-connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEnabled=true&httpPpgradeEndpoint=http-acceptor&port=8180&host=192-168-99-101
> 2016-04-04 16:32:46,480 DEBUG [org.apache.activemq.artemis.core.client] (Thread-6 (ActiveMQ-client-global-threads-1863167529)) Started Netty Connector version 4.0.30.Final
> 2016-04-04 16:32:46,480 DEBUG [org.apache.activemq.artemis.core.client] (Thread-6 (ActiveMQ-client-global-threads-1863167529)) Remote destination: /192.168.99.101:8180
> 2016-04-04 16:32:47,495 DEBUG [org.apache.activemq.artemis.core.client] (Thread-6 (ActiveMQ-client-global-threads-1863167529)) Connector towards NettyConnector [host=192.168.99.101, port=8180, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true] failed
> 2016-04-04 16:32:47,499 DEBUG [org.apache.activemq.artemis.core.client] (Thread-6 (ActiveMQ-client-global-threads-1863167529)) Started Netty Connector version 4.0.30.Final
> 2016-04-04 16:32:47,499 DEBUG [org.apache.activemq.artemis.core.client] (Thread-6 (ActiveMQ-client-global-threads-1863167529)) Remote destination: /192.168.99.101:8180
> 2016-04-04 16:32:48,524 DEBUG [org.apache.activemq.artemis.core.client] (Thread-6 (ActiveMQ-client-global-threads-1863167529)) Connector towards NettyConnector [host=192.168.99.101, port=8180, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true] failed
> 2016-04-04 16:32:48,526 DEBUG [org.apache.activemq.artemis.core.client] (Thread-6 (ActiveMQ-client-global-threads-1863167529)) Backup is not active.
> {noformat}
> and does not failover to the second server.
> Client log file (client.log) as well as both server instances logs attached (master.log, slave.log).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ELY-483) GssapiTestSuite and Gs2Test fail with com.ibm.security.krb5.KrbException, status code: 9 for IBM JDK
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/ELY-483?page=com.atlassian.jira.plugin.sy... ]
Ondrej Lukas commented on ELY-483:
----------------------------------
Issue can be fixed by using {{aes128-cts-hmac-sha1-96}} instead of used {{des-cbc-md5,des3-cbc-sha1-kd}} in default_tgs_enctypes and default_tkt_enctypes in krb5.conf. However this modification leads to test failures in following tests (with all JDKs):
org.wildfly.security.sasl.gssapi.compatibility.BasicAuthTest.testAuth
org.wildfly.security.sasl.gssapi.compatibility.BasicConfidenceTest.testAuthConf
org.wildfly.security.sasl.gssapi.compatibility.BasicIntegrityTest.testAuthInt
org.wildfly.security.sasl.gssapi.compatibility.NoServerAuthTest.testAuth
They fail with org.junit.ComparisonFailure. Thrown exception (for BasicAuthTest):
{code}
org.junit.ComparisonFailure: expected:<60820[20406092a864886f71201020201006e8201f3308201efa003020105a10302010ea20703050020000000a382010b6182010730820103a003020105a10d1b0b57494c44464c592e4f5247a220301ea003020100a11730151b047361736c1b0d746573745f7365727665725f31a381ca3081c7a003020110a281bf0481bc35c0e8fcda8a25bc04a0f0b15bd2007a8eaf706c6e282746f2520a0df3b2981a5c550647ac08cca70c8591e3e9f85c166f0b64a30af8c77b185cc8c3708e6d113ba90fca1a47e21540fedfc8b92e2427e601ba7d6c304483bf43bc85a8efe9936004c5b0132700426dd4427478338a389f6e0dec8125a7ec571859866349f9604730e45373bd956d86814943d8a1b11c9cf5a84c5722a5a665f7705884fc14b0d74c16547c92ec8b561c7c07f7ea6cdea07286ac4c4a2187a15e775da481ca3081c7a003020110a281bf0481bc7b05b4ad61dc02fb178b29d6aa5d79f05ee5d0c23a99204525c4927824b390f5ebd1cadcaa97ead6c3bdaf8c11d6c6e45c7b9270a9ddc44c52c6fe7ac29456590c3981aedc84aaad551dbcec2b9b930841713bff6d18f7df4e7ef27dafd06a60a7c2eeb1c18dd3d49579f98aca996eefda0741a98f2aa3f43328b29273e0c7984add0ebc10d77e11b099f9414d5c2d7330da9dcb090099f9d4985f924c6b524b97078589c10483df52419e2e0a8782f092705cea03807607c1f7c2d5]> but was:<60820[1ea06092a864886f71201020201006e8201d9308201d5a003020105a10302010ea20703050020000000a381fe6181fb3081f8a003020105a10d1b0b57494c44464c592e4f5247a220301ea003020100a11730151b047361736c1b0d746573745f7365727665725f31a381bf3081bca003020111a281b40481b1272e8ac7a1076eb28b918843a0895247793a142ec9ed9594714ef580f82a1746394397cca3f2c51c2eddce8fee723b8183c41da459c4124d5e9f75cf64f76303adefa67e8829d2dcd50531a7dcbf378481b35929ae30b96079b7c7b26d511680c67705b76aa1df3386128d4ead0347f3d0c7e77de49fd6fd0630fb9c3d4a509aa492fa0f3a38b2875957be56d6ae3ae59afd5316c5eca24000513533c105b8585d488b236d311ef151090b9ea17081b47fa481be3081bba003020111a281b30481b0da333a40f41650b8fad4cc74daca10d547a683ccba10adca1141e96823fafb5e60606178e5762d5bcfad806c9e8491fa71c0ba8d06d8f7c47ff44af5f15769eac46db39a791b1b0751a2d855af15f78cc18afe128f4feab642d89b8f185229c2ec95b8758694ca443a525522bc6e11c5f1c62a8015c0a73ed09a2a942a939d97a1cb026eed1d45d04b898a7159cb8ab87f4a8332b6c950f8c50f40cd9ceed1845f6cf5a2f2a2cbe170bb34db4ff61a59]>
at org.wildfly.security.sasl.gssapi.compatibility.BasicAuthTest.testAuth(BasicAuthTest.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
{code}
> GssapiTestSuite and Gs2Test fail with com.ibm.security.krb5.KrbException, status code: 9 for IBM JDK
> ----------------------------------------------------------------------------------------------------
>
> Key: ELY-483
> URL: https://issues.jboss.org/browse/ELY-483
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta5
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> Test cases initialization from GssapiTestSuite and Gs2Test fail with following exception for IBM JDK:
> {code}
> javax.security.auth.login.FailedLoginException:
> Login error: com.ibm.security.krb5.KrbException, status code: 9
> message: The client or server has a null key
> at com.ibm.security.jgss.i18n.I18NException.throwFailedLoginException(I18NException.java:15)
> at com.ibm.security.auth.module.Krb5LoginModule.j(Krb5LoginModule.java:727)
> at com.ibm.security.auth.module.Krb5LoginModule.b(Krb5LoginModule.java:307)
> at com.ibm.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:59)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:788)
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:196)
> at javax.security.auth.login.LoginContext$5.run(LoginContext.java:721)
> at javax.security.auth.login.LoginContext$5.run(LoginContext.java:719)
> at java.security.AccessController.doPrivileged(AccessController.java:686)
> at javax.security.auth.login.LoginContext.invokeCreatorPriv(LoginContext.java:719)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:593)
> at org.wildfly.security.sasl.gssapi.JaasUtil.login(JaasUtil.java:71)
> at org.wildfly.security.sasl.gssapi.JaasUtil.loginClient(JaasUtil.java:53)
> at org.wildfly.security.sasl.gssapi.JdkClientJdkServer.initialise(JdkClientJdkServer.java:47)
> ...
> {code}
> It is test case issue but it can hide any another functional issue because affected tests are not running with IBM JDK.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ELY-483) GssapiTestSuite and Gs2Test fail with com.ibm.security.krb5.KrbException, status code: 9 for IBM JDK
by Ondrej Lukas (JIRA)
Ondrej Lukas created ELY-483:
--------------------------------
Summary: GssapiTestSuite and Gs2Test fail with com.ibm.security.krb5.KrbException, status code: 9 for IBM JDK
Key: ELY-483
URL: https://issues.jboss.org/browse/ELY-483
Project: WildFly Elytron
Issue Type: Bug
Affects Versions: 1.1.0.Beta5
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
Test cases initialization from GssapiTestSuite and Gs2Test fail with following exception for IBM JDK:
{code}
javax.security.auth.login.FailedLoginException:
Login error: com.ibm.security.krb5.KrbException, status code: 9
message: The client or server has a null key
at com.ibm.security.jgss.i18n.I18NException.throwFailedLoginException(I18NException.java:15)
at com.ibm.security.auth.module.Krb5LoginModule.j(Krb5LoginModule.java:727)
at com.ibm.security.auth.module.Krb5LoginModule.b(Krb5LoginModule.java:307)
at com.ibm.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:59)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:507)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:788)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:196)
at javax.security.auth.login.LoginContext$5.run(LoginContext.java:721)
at javax.security.auth.login.LoginContext$5.run(LoginContext.java:719)
at java.security.AccessController.doPrivileged(AccessController.java:686)
at javax.security.auth.login.LoginContext.invokeCreatorPriv(LoginContext.java:719)
at javax.security.auth.login.LoginContext.login(LoginContext.java:593)
at org.wildfly.security.sasl.gssapi.JaasUtil.login(JaasUtil.java:71)
at org.wildfly.security.sasl.gssapi.JaasUtil.loginClient(JaasUtil.java:53)
at org.wildfly.security.sasl.gssapi.JdkClientJdkServer.initialise(JdkClientJdkServer.java:47)
...
{code}
It is test case issue but it can hide any another functional issue because affected tests are not running with IBM JDK.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ELY-482) JaasUtil class in test using options unrecognized by IBM JDK
by Ondrej Lukas (JIRA)
Ondrej Lukas created ELY-482:
--------------------------------
Summary: JaasUtil class in test using options unrecognized by IBM JDK
Key: ELY-482
URL: https://issues.jboss.org/browse/ELY-482
Project: WildFly Elytron
Issue Type: Bug
Affects Versions: 1.1.0.Beta5
Reporter: Ondrej Lukas
Assignee: Ondrej Lukas
Priority: Minor
IBM JDK is not able to work with options set in method createGssProxyConfiguration from org.wildfly.security.sasl.gssapi.JaasUtil class used by tests.
Following options are unrecognized by IBM JDK: "useKeyTab", "keyTab", "doNotPrompt".
On the other hand, following option must be used for IBM JDK: "useKeytab".
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ELY-481) SSLAuthenticationTest fails with java.security.NoSuchAlgorithmException: SunX509 KeyManagerFactory not available for IBM JDK
by Ondrej Lukas (JIRA)
Ondrej Lukas created ELY-481:
--------------------------------
Summary: SSLAuthenticationTest fails with java.security.NoSuchAlgorithmException: SunX509 KeyManagerFactory not available for IBM JDK
Key: ELY-481
URL: https://issues.jboss.org/browse/ELY-481
Project: WildFly Elytron
Issue Type: Bug
Affects Versions: 1.1.0.Beta5
Reporter: Ondrej Lukas
Assignee: Ondrej Lukas
Priority: Minor
This is only test case issue.
Running SSLAuthenticationTest with IBM JDK fails with:
{code}
java.security.NoSuchAlgorithmException: SunX509 KeyManagerFactory not available
at sun.security.jca.GetInstance.getInstance(GetInstance.java:171)
at javax.net.ssl.KeyManagerFactory.getInstance(KeyManagerFactory.java:20)
at org.wildfly.security.ssl.SSLAuthenticationTest.getKeyManager(SSLAuthenticationTest.java:101)
at org.wildfly.security.ssl.SSLAuthenticationTest.setupServer(SSLAuthenticationTest.java:79)
...
{code}
It is caused by calling KeyManagerFactory.getInstance with value "SunX509" for IBM JDK. However IBM JDK should use "IbmX509".
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6491) Undertow subsystem is misleading about listener capabilities
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6491?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-6491:
--------------------------------------
I think this attribute should be deprecated, and the semantics changes so that if the listener is not enabled the service still starts however it does not actually listen.
> Undertow subsystem is misleading about listener capabilities
> ------------------------------------------------------------
>
> Key: WFLY-6491
> URL: https://issues.jboss.org/browse/WFLY-6491
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Brian Stansberry
> Assignee: Stuart Douglas
>
> ListenerResourceDefinition registers the LISTENER_CAPABILITY regardless of the value of the 'enabled' attribute. But the contract provided by that capability is only fulfilled if the attribute is 'true'.
> Even worse, the attribute supports expressions, which can only be reliably resolved in Stage.RUNTIME, which is too late for recording a capability.
> Fortunately, it's vault resolution that makes it necessary to resolve in RUNTIME and reality is people are highly unlikely to use the vault for this expression, so we can try and resolve and hope for the best.
> This enabled stuff is just the worst. DON'T USE THIS CONCEPT IN YOUR MODEL!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6489) Distributable session may not exist after redirect to same node with optimistic locking.
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6489?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on WFLY-6489 at 4/4/16 8:01 PM:
------------------------------------------------------------
Is there a particular reason why you are using optimistic locking? Optimistic locking will permit dirty reads - which explains your observations. Your use case requires PESSIMISTIC locking + REPEATABLE_READ isolation (i.e. the defaults).
was (Author: pferraro):
Is there a particular reason why you are using optimistic locking? For most users, I wouldn't recommend any configuration other than PESSIMISTIC+REPEATABLE_READ (i.e. the defaults).
> Distributable session may not exist after redirect to same node with optimistic locking.
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-6489
> URL: https://issues.jboss.org/browse/WFLY-6489
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.2.1.Final, 10.0.0.Final, 10.1.0.Final
> Reporter: Gabriel Lavoie
> Assignee: Paul Ferraro
> Priority: Critical
> Attachments: wildfly-10-session-issue.zip
>
>
> I'm currently working on porting an application running on EAP 6.1 to WildFly 10 and am encountering multiple session/authentication issues with clustering enabled. Our login flow currently starts from a servlet that accepts the credentials, creates the session, then redirect to the welcome page.
> The first time we execute this flow after the startup of a node, the welcome page can't see at all the session created previously.
> - request.getSession() creates yet another session and a new session cookie is returned.
> - request.getSession(false) returns "null"
> On the second attempt, the flow works as expected.
> The issue can be reproduced on both a single node or a two nodes cluster, as long as <distributable /> is enabled in web.xml.
> We are currently using the master build https://ci.jboss.org/hudson/job/WildFly-latest-master/2244/, but the problem has been noticed on 10.0.0-Final and also 8.2.1-Final.
> I attached a sample web application that I used to reproduce the issue. Our standalone.xml is also included with the clustering configuration we've been using for the web/session cache.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6489) Distributable session may not exist after redirect to same node with optimistic locking.
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6489?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on WFLY-6489 at 4/4/16 7:57 PM:
------------------------------------------------------------
Is there a particular reason why you are using optimistic locking? For most users, I wouldn't recommend any configuration other than PESSIMISTIC+REPEATABLE_READ (i.e. the defaults).
was (Author: pferraro):
Is there are reason why you are using optimistic locking? For most users, I wouldn't recommend any configuration other than PESSIMISTIC+REPEATABLE_READ (i.e. the defaults).
> Distributable session may not exist after redirect to same node with optimistic locking.
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-6489
> URL: https://issues.jboss.org/browse/WFLY-6489
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.2.1.Final, 10.0.0.Final, 10.1.0.Final
> Reporter: Gabriel Lavoie
> Assignee: Paul Ferraro
> Priority: Critical
> Attachments: wildfly-10-session-issue.zip
>
>
> I'm currently working on porting an application running on EAP 6.1 to WildFly 10 and am encountering multiple session/authentication issues with clustering enabled. Our login flow currently starts from a servlet that accepts the credentials, creates the session, then redirect to the welcome page.
> The first time we execute this flow after the startup of a node, the welcome page can't see at all the session created previously.
> - request.getSession() creates yet another session and a new session cookie is returned.
> - request.getSession(false) returns "null"
> On the second attempt, the flow works as expected.
> The issue can be reproduced on both a single node or a two nodes cluster, as long as <distributable /> is enabled in web.xml.
> We are currently using the master build https://ci.jboss.org/hudson/job/WildFly-latest-master/2244/, but the problem has been noticed on 10.0.0-Final and also 8.2.1-Final.
> I attached a sample web application that I used to reproduce the issue. Our standalone.xml is also included with the clustering configuration we've been using for the web/session cache.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month