Andre, if you happen to use the Spring Framework already, we have a
milestone release (version 4.0 M1) that provides fallback options based on
the SockJS protocol. The next milestone 2 due in a week will provide higher
level (sub-protocol) support for messaging patterns such as pub-sub and
point-to
On Fri, Jul 5, 2013 at 3:40 AM, André Warnier wrote:
> We're still one level remote of thinking of any implementation, and trying
> to understand
> 1) how exactly websockets works
>
Most websocket implementations (RI/glassfish, atmosphere, tomcat, etc...)
are open source, so diving in the code i
Howard W. Smith, Jr. wrote:
On Thu, Jul 4, 2013 at 1:43 PM, Pierre Goupil wrote:
Regarding browser support, a framework like Atmosphere handles pretty well
having WebSockets when they are available and falling-back to another Comet
implementation (such as long-polling or http-streaming) when th
On Thu, Jul 4, 2013 at 1:43 PM, Pierre Goupil wrote:
> Regarding browser support, a framework like Atmosphere handles pretty well
> having WebSockets when they are available and falling-back to another Comet
> implementation (such as long-polling or http-streaming) when they are not.
>
agreed, bu
Regarding browser support, a framework like Atmosphere handles pretty well
having WebSockets when they are available and falling-back to another Comet
implementation (such as long-polling or http-streaming) when they are not.
Le 4 juil. 2013 17:12, "Mark Thomas" a écrit :
> On 04/07/2013 15:52, A
On 04/07/2013 15:52, André Warnier wrote:
> Mark Thomas wrote:
>> On 04/07/2013 10:17, André Warnier wrote:
>>> To me that means that at some point, there must be on the server side a
>>> process or thread which is dedicated to this websocket client for as
>>> long as it takes, and this process/thr
On Thu, Jul 4, 2013 at 5:52 PM, André Warnier wrote:
> Mark Thomas wrote:
>
>> On 04/07/2013 10:17, André Warnier wrote:
>>
>>> To me that means that at some point, there must be on the server side a
>>> process or thread which is dedicated to this websocket client for as
>>> long as it takes, an
Mark Thomas wrote:
On 04/07/2013 10:17, André Warnier wrote:
To me that means that at some point, there must be on the server side a
process or thread which is dedicated to this websocket client for as
long as it takes, and this process/thread in the meantime is no longer
available to process ot
On 04/07/2013 10:17, André Warnier wrote:
> To me that means that at some point, there must be on the server side a
> process or thread which is dedicated to this websocket client for as
> long as it takes, and this process/thread in the meantime is no longer
> available to process other HTTP reque
Hi Andre,
On Thu, Jul 4, 2013 at 12:17 PM, André Warnier wrote:
> I'll just add a little bit of info (and guesses) below.
>
> Jess Holle wrote:
>
>> Unfortunately I don't have any information -- just related questions.
>>
>> 1. For someone currently using Apache httpd+mod_jk to load balance
>>
I'll just add a little bit of info (and guesses) below.
Jess Holle wrote:
Unfortunately I don't have any information -- just related questions.
1. For someone currently using Apache httpd+mod_jk to load balance
requests, what does one do about load balancing WebSockets requests
between To
Unfortunately I don't have any information -- just related questions.
1. For someone currently using Apache httpd+mod_jk to load balance
requests, what does one do about load balancing WebSockets requests
between Tomcat instances?
* As Andre alluded to, the only mention of websocket ha
12 matches
Mail list logo
