Skip to main content

[jsr356-experts] Re: Multithreading Options

  • From: Joe Walnes < >
  • To:
  • Subject: [jsr356-experts] Re: Multithreading Options
  • Date: Thu, 9 Aug 2012 10:43:20 -0500

I agree that sharing a full blown HttpSession introduces a lot of complexity, and if we can avoid it, we should.

Authentication is really the only case I can think of where state needs to be shared, so maybe we can specifically handle this, rather than coming up with a general catch-all solution.

If the EndPoint instance had access to the user principal (and maybe the URI and headers from the original request, to allow other pieces of information to be passed from a web-page to a WebSocket), that should me enough, right?

On Thu, Aug 9, 2012 at 9:03 AM, Justin Lee < " target="_blank"> > wrote:
i'm with greg on this one.  In grizzly, we'd create a new WebSocket per connection and save state there.  In the WebSocketApplication class, there was an overridable factory method that allowed for specialization at the application layer that let the app author do whatever was needed.  With access into the Application from a WebSocket, state could be shared exposed as needed.  I'm not entirely sure we need to work too hard to deal with things like shared credentials on multiple connections from a client since muxing alleviate that multiple connection problem when it lands.  That said, it's up for debate how much we want to plan around impending features (that might be impending for a year+) or just design to what we have *now* that we know browsers and clients support.


On Wed, Aug 8, 2012 at 7:56 PM, Joe Walnes < " target="_blank"> > wrote:


On Wed, Aug 8, 2012 at 6:47 PM, Greg Wilkins < " target="_blank"> > wrote:
On 5 August 2012 19:05, Mark Thomas < " target="_blank"> > wrote:
> The question this raises for me is what is the mechanism going to be for
> retaining state? i.e. what is the WebSocket equivalent of HttpSession
> going to be? The follow-on question is how is state information
> transferred between the WebSocketSession (for want of a better name
> right now) and the HttpSession.

In my websocket work to date, having websocket session has not been an
issue as we create an EndPoint per connection as a new object that can
hold state.

That's true, but there's also some state that needs to be shared between connections such as authentication credentials.




--




[jsr356-experts] Re: Multithreading Options

Mark Thomas 08/05/2012

<Possible follow-up(s)>

[jsr356-experts] Re: Multithreading Options

Mark Thomas 08/05/2012

[jsr356-experts] Re: Multithreading Options

Greg Wilkins 08/08/2012

[jsr356-experts] Re: Multithreading Options

Joe Walnes 08/08/2012

[jsr356-experts] Re: Multithreading Options

Justin Lee 08/09/2012

[jsr356-experts] Re: Multithreading Options

Joe Walnes 08/09/2012

[jsr356-experts] Re: [jsr356-users] Re: Multithreading Options

Danny Coward 08/09/2012

[jsr356-experts] Re: [jsr356-users] Re: Multithreading Options

Greg Wilkins 08/11/2012

[jsr356-experts] Re: [jsr356-users] Re: Multithreading Options

Justin Lee 08/11/2012

[jsr356-experts] Re: [jsr356-users] Re: Multithreading Options

Mark Thomas 08/11/2012
 
 
Close
loading
Please Confirm
Close