[JBoss JIRA] (WFLY-6489) Distributable session may not exist after redirect to same node with optimistic locking.
by Gabriel Lavoie (JIRA)
[ https://issues.jboss.org/browse/WFLY-6489?page=com.atlassian.jira.plugin.... ]
Gabriel Lavoie edited comment on WFLY-6489 at 4/4/16 2:05 PM:
--------------------------------------------------------------
When attempting to diagnose the issue, I found out that response.sendRedirect() flushes immediately the response that includes the Location header. This causes the browser to hit immediately the new URL before the previous call had the chance to complete. This can cause issues when filters are getting unstacked and they need to set session data (in the existing session) before the redirection occurs.
A good example of this is the Spring [SecurityContextPersistenceFilter|https://github.com/spring-projects/sprin...] that will persist the security context into the session only when the servlet request is completed and the filters are being unstacked. The next call may not yet see the security context.
I verified the behavior with EAP 6.1, Tomcat 8 and Glassfish 4 and they flush the headers only when everything related to the request has been processed.
Please tell me if I should open a new bug ticket for this other change of behavior.
was (Author: glavoie):
When attempting to diagnose the issue, I found out that response.sendRedirect() flushes immediately the response that includes the Location header. This causes the browser to hit immediately the new URL before the previous call had the chance to complete. This can cause issues when filters are getting unstacked and they need to set session data (in the existing session) before the redirection occurs.
A good example of this is the Spring [link SecurityContextPersistenceFilter|https://github.com/spring-projects/sprin...] that will persist the security context into the session only when the servlet request is completed and the filters are being unstacked. The next call may not yet see the security context.
I verified the behavior with EAP 6.1, Tomcat 8 and Glassfish 4 and they flush the headers only when everything related to the request has been processed.
Please tell me if I should open a new bug ticket for this other change of behavior.
> 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 Gabriel Lavoie (JIRA)
[ https://issues.jboss.org/browse/WFLY-6489?page=com.atlassian.jira.plugin.... ]
Gabriel Lavoie edited comment on WFLY-6489 at 4/4/16 2:04 PM:
--------------------------------------------------------------
When attempting to diagnose the issue, I found out that response.sendRedirect() flushes immediately the response that includes the Location header. This causes the browser to hit immediately the new URL before the previous call had the chance to complete. This can cause issues when filters are getting unstacked and they need to set session data (in the existing session) before the redirection occurs.
A good example of this is the Spring [link SecurityContextPersistenceFilter|https://github.com/spring-projects/sprin...] that will persist the security context into the session only when the servlet request is completed and the filters are being unstacked. The next call may not yet see the security context.
I verified the behavior with EAP 6.1, Tomcat 8 and Glassfish 4 and they flush the headers only when everything related to the request has been processed.
Please tell me if I should open a new bug ticket for this other change of behavior.
was (Author: glavoie):
When attempting to diagnose the issue, I found out that response.sendRedirect() flushes immediately the response that includes the Location header. This causes the browser to hit immediately the new URL before the previous call had the chance to complete. This can cause issues when filters are getting unstacked and they need to set session data (in the existing session) before the redirection occurs.
A good example of this is the Spring SecurityContextPersistenceFilter that will persist the security context into the session only when the servlet request is completed and the filters are being unstacked. The next call may not yet see the security context.
I verified the behavior with EAP 6.1, Tomcat 8 and Glassfish 4 and they flush the headers only when everything related to the request has been processed.
Please tell me if I should open a new bug ticket for this other change of behavior.
> 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 Gabriel Lavoie (JIRA)
[ https://issues.jboss.org/browse/WFLY-6489?page=com.atlassian.jira.plugin.... ]
Gabriel Lavoie commented on WFLY-6489:
--------------------------------------
When attempting to diagnose the issue, I found out that response.sendRedirect() flushes immediately the response that includes the Location header. This causes the browser to hit immediately the new URL before the previous call had the chance to complete. This can cause issues when filters are getting unstacked and they need to set session data (in the existing session) before the redirection occurs.
A good example of this is the Spring SecurityContextPersistenceFilter that will persist the security context into the session only when the servlet request is completed and the filters are being unstacked. The next call may not yet see the security context.
I verified the behavior with EAP 6.1, Tomcat 8 and Glassfish 4 and they flush the headers only when everything related to the request has been processed.
Please tell me if I should open a new bug ticket for this other change of behavior.
> 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 Gabriel Lavoie (JIRA)
Gabriel Lavoie created WFLY-6489:
------------------------------------
Summary: 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: 10.0.0.Final, 8.2.1.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-6487) add JPA dependency in subdeployments to avoid NPE
by Scott Marlow (JIRA)
Scott Marlow created WFLY-6487:
----------------------------------
Summary: add JPA dependency in subdeployments to avoid NPE
Key: WFLY-6487
URL: https://issues.jboss.org/browse/WFLY-6487
Project: WildFly
Issue Type: Bug
Components: CDI / Weld, JPA / Hibernate
Affects Versions: 10.0.0.Final
Reporter: Scott Marlow
Assignee: Scott Marlow
Avoid the following NPE by ensuring that dependencies on the JPA persistence unit are added for all sub-deployments.
{quote}
Caused by: java.lang.NullPointerException
at org.jboss.as.jpa.container.TransactionScopedEntityManager.createEntityManager(TransactionScopedEntityManager.java:186)
at org.jboss.as.jpa.container.TransactionScopedEntityManager.getEntityManager(TransactionScopedEntityManager.java:91)
at org.jboss.as.jpa.container.AbstractEntityManager.find(AbstractEntityManager.java:212)
{quote}
Potential fix is at [https://github.com/scottmarlow/wildfly/tree/jpaNPE]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6486) Standalone JMS client of 2 node colocated live/backup symmetrical cluster fails to failover.
by Michal Sudra (JIRA)
Michal Sudra created WFLY-6486:
----------------------------------
Summary: 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