[JBoss JIRA] (WFLY-9282) UserTransaction should be lazy to allow node selection (loadbalancing) even if the invocations stick to one node
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-9282?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-9282:
-----------------------------------
Per discussions, this may be fully resolved already. Let's see if we can close this out.
> UserTransaction should be lazy to allow node selection (loadbalancing) even if the invocations stick to one node
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9282
> URL: https://issues.jboss.org/browse/WFLY-9282
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Environment: Remote client EJB invocation
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
>
> It should be possible to lookup a UserTransaction from a node or a cluster and call .begin() with starting the Transaction lazy until the first EJB invocation.
> The invocation will implicit begin the transaction and all invocation are sticky to that node.
> This is to spread the load across several server instances if there is no running transaction but keep the transaction sticky to the first selected node.
> It prevents from a strong affinity to one instance via URI affinity or the necessity to define the node for the UserTransaction upfront.
> The sticiness is because of issues with persistence like JPA as here the server is not really 'stateless' as the session of EntityManager can decide to not flush the changed data to the underlying database which can cause issues if the transaction will continued on a different instance if the client invoke EJB's multiple times.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (JBWEB-214) More than one JSESSIONID cookie headers set in JBoss Web
by richard groote (JIRA)
[ https://issues.jboss.org/browse/JBWEB-214?page=com.atlassian.jira.plugin.... ]
richard groote commented on JBWEB-214:
--------------------------------------
I have a question about the status of this issue. In the rfc6265 the below is stated, so it would be nice if the server should not response with multiple session id.
In our situation we do not invalidate the session our self. In our situation we're calling a secure page and than the response contains two SetCookie headers.
The cause of the problem is the session-config in the web.xml defines that the cookie is secure but the call we make in the browser is http.
The next call is a post to the j_security_check and this one will fail with message "session timeout during the login process".
The browser (FireFox and Chrome) are not responding to (correctly) to the Set-Cookie in the first request so therefore a incorrect session is send with the j_security_check.
It would be nice if the server will response only with one Set-Cookie
--- RFC6265 ---
Servers SHOULD NOT include more than one Set-Cookie header field in
the same response with the same cookie-name. (See Section 5.2 for
how user agents handle this case.)
> More than one JSESSIONID cookie headers set in JBoss Web
> --------------------------------------------------------
>
> Key: JBWEB-214
> URL: https://issues.jboss.org/browse/JBWEB-214
> Project: JBoss Web
> Issue Type: Bug
> Components: Tomcat
> Affects Versions: JBossWeb-2.1.11.GA
> Reporter: Eiichi Nagai
> Assignee: Remy Maucherat
>
> More than one JSESSIONID cookie headers set if execute following JSP.
> <%
> session.invalidate();
> session = request.getSession();
> session.invalidate();
> session = request.getSession();
> %>
> This issue has been reported from Bug 49158[1] in tomcat.
> [1] Bug 49158 - More than one JSESSIONID cookie headers set
> https://issues.apache.org/bugzilla/show_bug.cgi?id=49158
> http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalin...
> http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalin...
> I guess that same fix is required in JBoss Web.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3545) Composed keys don't have to be recognized by CLI
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3545?page=com.atlassian.jira.plugi... ]
Erich Duda reassigned WFCORE-3545:
----------------------------------
Assignee: Jean-Francois Denise (was: Erich Duda)
> Composed keys don't have to be recognized by CLI
> ------------------------------------------------
>
> Key: WFCORE-3545
> URL: https://issues.jboss.org/browse/WFCORE-3545
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 4.0.0.Alpha6
> Reporter: Erich Duda
> Assignee: Jean-Francois Denise
>
> Some keys like key down are composed from multiple characters. Normally when the key down is pushed, 3 characters are written into stdin. These 3 characters are read by InputStream::read operation at once and then decoded to the Key.DOWN constant.
> However there is no guarantee that InputStream::read operation returns all the 3 characters at once. It can return only first character and then remaining two. This actually happens in one test on Solaris and HPUX, where stdin is emulated by PipedInputStream.
> If the aforementioned situation happens, pushing of key down is decoded as pushing of two maybe three keys - ESC and some other key(s).
> The issue has low priority, because this behavior wasn't observed in real terminal with real input. It affects only testing.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3545) Composed keys don't have to be recognized by CLI
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3545?page=com.atlassian.jira.plugi... ]
Erich Duda reassigned WFCORE-3545:
----------------------------------
Assignee: Erich Duda (was: Jean-Francois Denise)
> Composed keys don't have to be recognized by CLI
> ------------------------------------------------
>
> Key: WFCORE-3545
> URL: https://issues.jboss.org/browse/WFCORE-3545
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 4.0.0.Alpha6
> Reporter: Erich Duda
> Assignee: Erich Duda
>
> Some keys like key down are composed from multiple characters. Normally when the key down is pushed, 3 characters are written into stdin. These 3 characters are read by InputStream::read operation at once and then decoded to the Key.DOWN constant.
> However there is no guarantee that InputStream::read operation returns all the 3 characters at once. It can return only first character and then remaining two. This actually happens in one test on Solaris and HPUX, where stdin is emulated by PipedInputStream.
> If the aforementioned situation happens, pushing of key down is decoded as pushing of two maybe three keys - ESC and some other key(s).
> The issue has low priority, because this behavior wasn't observed in real terminal with real input. It affects only testing.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months