[JBoss JIRA] (JGRP-1436) GMS: separate view bundling timeouts for JOIN, LEAVE, MERGE
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1436?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1436:
--------------------------------
Don't think I want to do this as it complicates the code; having separate timeouts for joins, leaves and suspects (?) means we'd have to maintain 3 instead of 1 queue in GMS.ViewHandler.
Keeping GMS.max_bundling_time sufficiently small, e.g. 50-500ms, guarantees speedy processing of those events.
> GMS: separate view bundling timeouts for JOIN, LEAVE, MERGE
> -----------------------------------------------------------
>
> Key: JGRP-1436
> URL: https://issues.jboss.org/browse/JGRP-1436
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4
>
>
> View bundling in GMS bundles events based on (1) whether they can be processed together and (2) whether a view bundling timeout is defined. The latter timeout is for all events, perhaps we want to define separate timeouts, e.g. the timeout for JOINs is 3000, but for LEAVE it is 500. This means that when we get multiple JOIN events, we'll wait up to 5 seconds and then process them together. When we get multiple LEAVE requests, we only wait for half a second before processing them. This causes LEAVEs to be processed almost immediately, whereas JOINs are bundled.
> Also revisit the code which determines which events can be processed together. Perhaps MERGE events can be bundled, too ?
--
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, 9 months
[JBoss JIRA] (JGRP-1487) X509Token Authentication is vulnerable to replay attacks
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1487?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1487:
---------------------------
Fix Version/s: Future
(was: 3.4)
No response, moved to Future
> X509Token Authentication is vulnerable to replay attacks
> --------------------------------------------------------
>
> Key: JGRP-1487
> URL: https://issues.jboss.org/browse/JGRP-1487
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.0.9
> Reporter: sreenivas chinimilli
> Assignee: Bela Ban
> Fix For: Future
>
>
> In the implementation of X509Token Authentication
> The auth_value is enrypted with the certificate within the keystore and
> during verification encrypted auth value is decrypted with the private key
> compared against the orignial auth value.
> This implementation is prone to replay attacks, that is
> any user with out having any knowledge of the auth value can join the group
> by replaying the enrypted auth value captured in earlier sessions.
--
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, 9 months
[JBoss JIRA] (JGRP-1658) GMS: Node re-joining the cluster during shutdown
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1658?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1658.
----------------------------
Resolution: Won't Fix
We be fixed by upgrading from UNICAST2 to UNICAST3, as per the comments.
> GMS: Node re-joining the cluster during shutdown
> ------------------------------------------------
>
> Key: JGRP-1658
> URL: https://issues.jboss.org/browse/JGRP-1658
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3.1
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Fix For: 3.4
>
> Attachments: pfapt.log.gz
>
>
> We have RSVP in the stack, with ack_on_delivery=true.
> It seems that node C receives a RSVP-flagged message just after it sent the LEAVE_REQ to A, and immediately after sending the RSVP ACK it sends a JOIN_REQ as well.
> {noformat}
> 11:55:54,524 DEBUG (testng:) [DefaultCacheManager] Stopping cache manager ISPN on C
> 11:55:54,525 DEBUG (testng:) [GMS] C: sending LEAVE request to A
> 11:55:54,525 TRACE (testng:) [TCP] C: sending msg to A, src=C, headers are GMS: GmsHeader[LEAVE_REQ]: mbr=C, UNICAST2: DATA, seqno=16, TCP: [channel_name=ISPN]
> 11:55:54,526 TRACE (ViewHandler,A:) [GMS] A: new members=[], suspected=[], leaving=[C], new view: [A|4] [A, B, D]
> 11:55:54,528 TRACE (OOB-3,C:) [TCP] C: received [dst: <null>, src: A (4 headers), size=7469 bytes, flags=OOB|DONT_BUNDLE|NO_TOTAL_ORDER|RSVP], headers are RequestCorrelator: id=200, type=REQ, id=93579, rsp_expected=false, exclusion_list=[A], RSVP: REQ(7), NAKACK2: [MSG, seqno=9], TCP: [channel_name=ISPN]
> 11:55:54,528 TRACE (OOB-3,C:) [TCP] C: sending msg to A, src=C, headers are RSVP: RSP(7), UNICAST2: DATA, seqno=17, TCP: [channel_name=ISPN]
> 11:55:54,529 TRACE (OOB-3,C:) [TCP] C: sending msg to A, src=C, headers are GMS: GmsHeader[JOIN_REQ]: mbr=C, UNICAST2: DATA, seqno=1, first, TCP: [channel_name=ISPN]
> 11:55:54,613 TRACE (ViewHandler,A:) [GMS] A: new members=[C], suspected=[], leaving=[], new view: [A|5] [A, B, D, C]
> 11:55:54,613 TRACE (ViewHandler,A:) [GMS] A: mcasting view [A|5] [A, B, D, C] (4 mbrs)
> 11:55:54,841 DEBUG (testng:) [TEST_PING] Stop discovery for C
> 11:55:54,841 DEBUG (testng:) [TCP] closing sockets and stopping threads
> 11:55:55,683 TRACE (Timer-5,A:) [TCP] A: sending msg to C, src=A, headers are GMS: GmsHeader[JOIN_RSP]: join_rsp=view: [A|5] [A, B, D, C], digest: B: [0 (0)], D: [0 (0)], A: [11 (11)], C: [0 (0)], UNICAST2: DATA, seqno=1, conn_id=4, first, TCP: [channel_name=ISPN]
> {noformat}
> A adds C back to the view, but C shuts down and will never receive the JOIN_RSP message. Instead, the remaining members keep logging this error message until they are shut down 3 minutes later:
> {noformat}
> 11:59:01,346 TRACE (TransferQueueBundler,D:) [TCP] 127.0.0.1:8003: failed connecting to 127.0.0.1:8002: java.net.ConnectException: Connection refused
> {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, 9 months
[JBoss JIRA] (JGRP-1658) GMS: Node re-joining the cluster during shutdown
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/JGRP-1658?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on JGRP-1658:
------------------------------------
We haven't switched to UNICAST3 yet, but I don't think we have a good reason not to. I'm ok with closing the issue.
> GMS: Node re-joining the cluster during shutdown
> ------------------------------------------------
>
> Key: JGRP-1658
> URL: https://issues.jboss.org/browse/JGRP-1658
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3.1
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Fix For: 3.4
>
> Attachments: pfapt.log.gz
>
>
> We have RSVP in the stack, with ack_on_delivery=true.
> It seems that node C receives a RSVP-flagged message just after it sent the LEAVE_REQ to A, and immediately after sending the RSVP ACK it sends a JOIN_REQ as well.
> {noformat}
> 11:55:54,524 DEBUG (testng:) [DefaultCacheManager] Stopping cache manager ISPN on C
> 11:55:54,525 DEBUG (testng:) [GMS] C: sending LEAVE request to A
> 11:55:54,525 TRACE (testng:) [TCP] C: sending msg to A, src=C, headers are GMS: GmsHeader[LEAVE_REQ]: mbr=C, UNICAST2: DATA, seqno=16, TCP: [channel_name=ISPN]
> 11:55:54,526 TRACE (ViewHandler,A:) [GMS] A: new members=[], suspected=[], leaving=[C], new view: [A|4] [A, B, D]
> 11:55:54,528 TRACE (OOB-3,C:) [TCP] C: received [dst: <null>, src: A (4 headers), size=7469 bytes, flags=OOB|DONT_BUNDLE|NO_TOTAL_ORDER|RSVP], headers are RequestCorrelator: id=200, type=REQ, id=93579, rsp_expected=false, exclusion_list=[A], RSVP: REQ(7), NAKACK2: [MSG, seqno=9], TCP: [channel_name=ISPN]
> 11:55:54,528 TRACE (OOB-3,C:) [TCP] C: sending msg to A, src=C, headers are RSVP: RSP(7), UNICAST2: DATA, seqno=17, TCP: [channel_name=ISPN]
> 11:55:54,529 TRACE (OOB-3,C:) [TCP] C: sending msg to A, src=C, headers are GMS: GmsHeader[JOIN_REQ]: mbr=C, UNICAST2: DATA, seqno=1, first, TCP: [channel_name=ISPN]
> 11:55:54,613 TRACE (ViewHandler,A:) [GMS] A: new members=[C], suspected=[], leaving=[], new view: [A|5] [A, B, D, C]
> 11:55:54,613 TRACE (ViewHandler,A:) [GMS] A: mcasting view [A|5] [A, B, D, C] (4 mbrs)
> 11:55:54,841 DEBUG (testng:) [TEST_PING] Stop discovery for C
> 11:55:54,841 DEBUG (testng:) [TCP] closing sockets and stopping threads
> 11:55:55,683 TRACE (Timer-5,A:) [TCP] A: sending msg to C, src=A, headers are GMS: GmsHeader[JOIN_RSP]: join_rsp=view: [A|5] [A, B, D, C], digest: B: [0 (0)], D: [0 (0)], A: [11 (11)], C: [0 (0)], UNICAST2: DATA, seqno=1, conn_id=4, first, TCP: [channel_name=ISPN]
> {noformat}
> A adds C back to the view, but C shuts down and will never receive the JOIN_RSP message. Instead, the remaining members keep logging this error message until they are shut down 3 minutes later:
> {noformat}
> 11:59:01,346 TRACE (TransferQueueBundler,D:) [TCP] 127.0.0.1:8003: failed connecting to 127.0.0.1:8002: java.net.ConnectException: Connection refused
> {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, 9 months
[JBoss JIRA] (JBAS-2861) HttpSession sharing between WAR modules
by Karmel Idarraga (JIRA)
[ https://issues.jboss.org/browse/JBAS-2861?page=com.atlassian.jira.plugin.... ]
Karmel Idarraga commented on JBAS-2861:
---------------------------------------
thank you Shaun.
> HttpSession sharing between WAR modules
> ---------------------------------------
>
> Key: JBAS-2861
> URL: https://issues.jboss.org/browse/JBAS-2861
> Project: Application Server 3 4 5 and 6
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Clustering, Web (Tomcat) service
> Affects Versions: JBossAS-3.2.6 Final, JBossAS-3.2.7 Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: No Release
>
>
> Creating a redacted version of JBAS-1909, which was opened as a non-public JIRA issue by a customer.
> Our J2EE application is composed of several modules, each one addressing one facet of our business process, and currently this application has one web module (WAR) and several JAR modules (EJB).
> We need to divide this web module into several smaller web modules.
> In order to separate our unique WAR file into several WARs we must guarantee HttpSession sharing. This is due to the fact that we have a lot of session attributes that are used throughout the entire application and we cannot afford to refactor the application, in fact, that's impossible.
> The security aspects for this requirement are completely addressed by the JBoss/Tomcat Single Sign-On mechanism but the session sharing requirements are not.
> The ideal scenario is to keep the same HttpSession (same object in the heap, same session ID) when authenticating into one application (HttpSession created) and then forwarding to another application.
> The current SSO mechanism allows the user to access the second application without reauthentication, as you know, but it creates a new HttpSession object. Also, if the two WARs have different session timeouts, if you access application A, migrates to application B, stays there until session in application A expires and then returns to application A from application B, a new HttpSession is also created in application A.
> The ideal solution is to have one unique, monolithic session to all web applications configured to share a common session. IBM WebSphere and BEA WebLogic do have this configuration and feature. Please check the links below in case you want more information:
> WebSphere Application Server V5: Sharing Session Context - http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/tips0215.ht...
> BEA Weblogic - Enabling Web applications to share the same session - http://e-docs.bea.com/wls/docs90/webapp/sessions.html
--
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, 9 months
[JBoss JIRA] (JBAS-9545) AS7: HttpSession sharing between WAR modules (Clone)
by Karmel Idarraga (JIRA)
[ https://issues.jboss.org/browse/JBAS-9545?page=com.atlassian.jira.plugin.... ]
Karmel Idarraga commented on JBAS-9545:
---------------------------------------
I have exactly the same problem. Any idea about how to solve it??
> AS7: HttpSession sharing between WAR modules (Clone)
> ----------------------------------------------------
>
> Key: JBAS-9545
> URL: https://issues.jboss.org/browse/JBAS-9545
> Project: Application Server 3 4 5 and 6
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Clustering, Web (Tomcat) service
> Affects Versions: Open To Community
> Reporter: Avner Linder
> Assignee: Brian Stansberry
> Fix For: No Release
>
>
> Creating a redacted version of JBAS-1909, which was opened as a non-public JIRA issue by a customer.
> Our J2EE application is composed of several modules, each one addressing one facet of our business process, and currently this application has one web module (WAR) and several JAR modules (EJB).
> We need to divide this web module into several smaller web modules.
> In order to separate our unique WAR file into several WARs we must guarantee HttpSession sharing. This is due to the fact that we have a lot of session attributes that are used throughout the entire application and we cannot afford to refactor the application, in fact, that's impossible.
> The security aspects for this requirement are completely addressed by the JBoss/Tomcat Single Sign-On mechanism but the session sharing requirements are not.
> The ideal scenario is to keep the same HttpSession (same object in the heap, same session ID) when authenticating into one application (HttpSession created) and then forwarding to another application.
> The current SSO mechanism allows the user to access the second application without reauthentication, as you know, but it creates a new HttpSession object. Also, if the two WARs have different session timeouts, if you access application A, migrates to application B, stays there until session in application A expires and then returns to application A from application B, a new HttpSession is also created in application A.
> The ideal solution is to have one unique, monolithic session to all web applications configured to share a common session. IBM WebSphere and BEA WebLogic do have this configuration and feature. Please check the links below in case you want more information:
> WebSphere Application Server V5: Sharing Session Context - http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/tips0215.ht...
> BEA Weblogic - Enabling Web applications to share the same session - http://e-docs.bea.com/wls/docs90/webapp/sessions.html
--
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, 9 months