GWT + Comet question (was Re: [Jean-Francois Arcand's Blog] New Comment Posted to 'Building GWT Comet based web app using Grizzly Comet'

[Jeanfrancois Arcand-2]

Salut,

foo@... wrote:

> A new comment has been posted on your blog Jean-Francois Arcand's Blog, on entry #9839 (Building GWT Comet based web app using Grizzly Comet).
>
>
> View this comment: <http://weblogs.java.net/blog/jfarcand/archive/2008/05/building_gwt_co.html>
> Edit this comment: <http://weblogs.java.net/mt/mt.cgi?__mode=view&blog_id=258&_type=comment&id=52752>
>
> IP Address: 64.125.132.43
> Name:
> Email Address: foo@...
> URL:
> Comments:
>
> Hi JF! I'm developing a GWT application using GWT-RPC and Grizzly. My application works fine using Long Poll connections but I'd like to notify the client using the Streaming mode.

  I tried to remove context.resumeCometHandler() but the GWT-RPC doesn't
receive the notification... Can you help me? Thanks.

Yes, can you post an example of the code you have implemented so far?
You are not notifying using CometEvent.TERMINATE events by any chance
(which might also resume the connection)?

Thanks

-- Jeanfrancois


>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[marcoflower]

// CLIENT
public void comet() {
        cometService.comet(new AsyncCallback() {

                 public void onFailure(Throwable caught) {
                }

                 public void onSuccess(Object result) {
                      Message msg = (Message) result;
                       cometService.comet(this);
                       ....
                 }
         });
}


// SERVER
class GWTCometHandler implements CometHandler<HttpServletResponse> {

       HttpServletResponse res;
       HttpServletRequest req;

         public void onEvent(CometEvent ce) throws IOException{
               System.out.println("onEvent");

                Message msg = (Message) ce.attachment();
               try {
                    String encoded =
                   RPC.encodeResponseForSuccess(CometServiceImpl.class.getMethod("comet"), msg);
               System.out.println("encoded=" + encoded);

                    PrintWriter writer = res.getWriter();
                   writer.write(encoded);
                    writer.flush();
                   cc.resumeCometHandler(this);
               }
              catch (SecurityException e) {
                    System.out.println("onEvent:e=" + e);
                   e.printStackTrace();
               }
               catch (SerializationException e) {
                   System.out.println("onEvent:e=" + e);
                  e.printStackTrace();
               }
               catch (NoSuchMethodException e) {
                  System.out.println("onEvent:e=" + e);
                 e.printStackTrace();
               }
          }

     ..........

Hi,

(I'm using GlassfishV2). I call the onEvent method using comet.notify(msg, CometEvent.NOTIFY)
Using this code my application works fine: when I receve a notification, I resume the connection (using cc.resumeCometHandler(this)),  the GWT-RPC call can receive its Message and then I have to recall cometService.comet(this) in order to receive next Message. But this is the long poll mode, that's right?
But I've got a very fast notifier and using the poll mode the client lost some notifications between the resume connection and the new connection...
For this reason I'd like to use the streaming mode. How can I developing it using GWT-RPC?

Thanks

Marco

[Gustav Trede-2]

Hello Marco,

Streaming mode is enabled by not resuming the connection after each event along with that the client does not try to close the connection after each event.

Streaming mode does per definition not prevent lost messages, it only lowers the probability.
(Even a streaming client will need to reconnect due to transport errors etc)

We are about to implement JMS support for comet, that will allow for durable subscriptions.

2009/1/21 marcoflower <marcofiore1983@...>

// CLIENT
public void comet() {
       cometService.comet(new AsyncCallback() {

                public void onFailure(Throwable caught) {
                }

                public void onSuccess(Object result) {
                      Message msg = (Message) result;
                      cometService.comet(this);
                      ....
                }
        });
}


// SERVER
class GWTCometHandler implements CometHandler<HttpServletResponse> {

      HttpServletResponse res;
      HttpServletRequest req;

        public void onEvent(CometEvent ce) throws IOException{
               System.out.println("onEvent");

               Message msg = (Message) ce.attachment();
               try {
                   String encoded =

RPC.encodeResponseForSuccess(CometServiceImpl.class.getMethod("comet"),
msg);
                   System.out.println("encoded=" + encoded);

                   PrintWriter writer = res.getWriter();
                   writer.write(encoded);
                   writer.flush();
                   cc.resumeCometHandler(this);
              }
              catch (SecurityException e) {
                   System.out.println("onEvent:e=" + e);
                   e.printStackTrace();
              }
              catch (SerializationException e) {
                  System.out.println("onEvent:e=" + e);
                  e.printStackTrace();
              }
              catch (NoSuchMethodException e) {
                 System.out.println("onEvent:e=" + e);
                 e.printStackTrace();
              }
         }

    ..........

Hi,

(I'm using GlassfishV2). I call the onEvent method using comet.notify(msg,
CometEvent.NOTIFY)
Using this code my application works fine: when I receve a notification, I
resume the connection (using cc.resumeCometHandler(this)),  the GWT-RPC call
can receive its Message and then I have to recall cometService.comet(this)
in order to receive next Message. But this is the long poll mode, that's
right?
But I've got a very fast notifier and using the poll mode the client lost
some notifications between the resume connection and the new connection...
For this reason I'd like to use the streaming mode. How can I developing it
using GWT-RPC?

Thanks

Marco
--
View this message in context: http://www.nabble.com/GWT-%2B-Comet-question-%28was-Re%3A--Jean-Francois-Arcand%27s-Blog--New-Comment-Posted-to-%27Building-GWT-Comet-based-web-app-using-Grizzly-Comet%27-tp21416392p21578011.html
Sent from the Grizzly - Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

--
your servant
 gustav trede

coding is art - not only something that  bring food on the table,
everybody should be able to feel proud about their code,
that they have performed their best considering the given conditions.

[Jeanfrancois Arcand-2]

Salut,

marcoflower wrote:

> // CLIENT
> public void comet() {
>         cometService.comet(new AsyncCallback() {
>
>         public void onFailure(Throwable caught) {
>                 }
>
>         public void onSuccess(Object result) {
>                       Message msg = (Message) result;
>                        cometService.comet(this);
>               ....
>         }
>          });
> }
>
>
> // SERVER
> class GWTCometHandler implements CometHandler<HttpServletResponse> {
>
>        HttpServletResponse res;
>        HttpServletRequest req;
>
> public void onEvent(CometEvent ce) throws IOException{
>                System.out.println("onEvent");

Make sure your synchronize the onEvent (just to reduce out of order
messages).

>
>        Message msg = (Message) ce.attachment();
>                try {
>            String encoded =
>                  
> RPC.encodeResponseForSuccess(CometServiceImpl.class.getMethod("comet"),
> msg);
>                System.out.println("encoded=" + encoded);
>
>            PrintWriter writer = res.getWriter();
>                    writer.write(encoded);
>            writer.flush();
>                    cc.resumeCometHandler(this);

>       }
>               catch (SecurityException e) {
>            System.out.println("onEvent:e=" + e);
>                    e.printStackTrace();
>                }
>       catch (SerializationException e) {
>           System.out.println("onEvent:e=" + e);
>                   e.printStackTrace();
>       }
>                catch (NoSuchMethodException e) {
>          System.out.println("onEvent:e=" + e);
>                  e.printStackTrace();
>       }
>           }
>
>      ..........
>
> Hi,
>
> (I'm using GlassfishV2). I call the onEvent method using comet.notify(msg,
> CometEvent.NOTIFY)
> Using this code my application works fine: when I receve a notification, I
> resume the connection (using cc.resumeCometHandler(this)),  the GWT-RPC call
> can receive its Message and then I have to recall cometService.comet(this)
> in order to receive next Message. But this is the long poll mode, that's
> right?

Right.

> But I've got a very fast notifier and using the poll mode the client lost
> some notifications between the resume connection and the new connection...
> For this reason I'd like to use the streaming mode. How can I developing it
> using GWT-RPC?

Just never call resumeCometHandler. That will means the connection will
stay suspended (streaming mode) forever.

Does it help?

A+

--Jeanfrancois


>
> Thanks
>
> Marco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[marcoflower]

>Just never call resumeCometHandler. That will means the connection will
>stay suspended (streaming mode) forever.

I tried to remove the resumeCometHandler call, but if I remove it the client can't receive messages... I think is a specific GWT-RPC problem.

Thanks

Marco

[Jeanfrancois Arcand-2]

Salut,

marcoflower wrote:
>> Just never call resumeCometHandler. That will means the connection will
>> stay suspended (streaming mode) forever.
>
> I tried to remove the resumeCometHandler call, but if I remove it the client
> can't receive messages... I think is a specific GWT-RPC problem.

Sorry for that. Can you send a test case (.war) that I can try? Which
GlassFish or Grizzly version are you using?

Thanks!

-- Jeanfrancois

>
> Thanks
>
> Marco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[marcoflower]

You can find the .war here http://www.marcofiore.it/GrizzlyTest.war
I'm using GlassFishV2 and Grizzly 1.0.19

Thanks

Marco

Jeanfrancois Arcand-2 wrote:

Salut,

marcoflower wrote:
>> Just never call resumeCometHandler. That will means the connection will
>> stay suspended (streaming mode) forever.
>
> I tried to remove the resumeCometHandler call, but if I remove it the client
> can't receive messages... I think is a specific GWT-RPC problem.

Sorry for that. Can you send a test case (.war) that I can try? Which
GlassFish or Grizzly version are you using?

Thanks!

-- Jeanfrancois

>
> Thanks
>
> Marco

---------------------------------------------------------------------
To unsubscribe, e-mail: [e-mail]
For additional commands, e-mail: [e-mail]

[Jeanfrancois Arcand-2]

Salut,

marcoflower wrote:
> You can find the .war here http://www.marcofiore.it/GrizzlyTest.war
> I'm using GlassFishV2 and Grizzly 1.0.19

Thanks. Can you file an issue here:

https://grizzly.dev.java.net/issues/

I'm swamped right now and I just don't want to forget (and another
commiter can also take a look :-)

Thanks

-- Jeanfrancois

>
> Thanks
>
> Marco
>
>
> Jeanfrancois Arcand-2 wrote:
>> Salut,
>>
>> marcoflower wrote:
>>>> Just never call resumeCometHandler. That will means the connection will
>>>> stay suspended (streaming mode) forever.
>>> I tried to remove the resumeCometHandler call, but if I remove it the
>>> client
>>> can't receive messages... I think is a specific GWT-RPC problem.
>> Sorry for that. Can you send a test case (.war) that I can try? Which
>> GlassFish or Grizzly version are you using?
>>
>> Thanks!
>>
>> -- Jeanfrancois
>>
>>> Thanks
>>>
>>> Marco
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[jewel_kader]

Hi marcoflower,

Does this long polling solution work in IE? I tried it in IE 6, 7, & 8. I got it not working in IE though no problem in Firefox.

Thanks

Jewel


You can find the .war here http://www.marcofiore.it/GrizzlyTest.war
I'm using GlassFishV2 and Grizzly 1.0.19

Thanks

Marco

Jeanfrancois Arcand-2 wrote:

Salut,

marcoflower wrote:
>> Just never call resumeCometHandler. That will means the connection will
>> stay suspended (streaming mode) forever.
>
> I tried to remove the resumeCometHandler call, but if I remove it the client
> can't receive messages... I think is a specific GWT-RPC problem.

Sorry for that. Can you send a test case (.war) that I can try? Which
GlassFish or Grizzly version are you using?

Thanks!

-- Jeanfrancois

>
> Thanks
>
> Marco

---------------------------------------------------------------------
To unsubscribe, e-mail: [e-mail]
For additional commands, e-mail: [e-mail]

[Jeanfrancois Arcand-2]

Salut,

jewel_kader wrote:
> Hi marcoflower,
>
> Does this long polling solution work in IE? I tried it in IE 6, 7, & 8. I
> got it not working in IE though no problem in Firefox.

I will eventually look at it (apology for that) :-( To help, can you
flush some comments like before invoking addCometHandler(..):

>         // for IE
>         writer.println("<!-- Comet is a programming technique that enables web servers to send data to the client without having any need for the client to request it. -->\n");
>         writer.flush();

I bet it will make it work. Keep me posted. If you can use Wireshark or
ngrep to snoop the network that would help me as well.

Thanks

-- Jeanfrancois

>
> Thanks
>
> Jewel
>
>
> marcoflower wrote:
>> You can find the .war here http://www.marcofiore.it/GrizzlyTest.war
>> I'm using GlassFishV2 and Grizzly 1.0.19
>>
>> Thanks
>>
>> Marco
>>
>>
>> Jeanfrancois Arcand-2 wrote:
>>> Salut,
>>>
>>> marcoflower wrote:
>>>>> Just never call resumeCometHandler. That will means the connection will
>>>>> stay suspended (streaming mode) forever.
>>>> I tried to remove the resumeCometHandler call, but if I remove it the
>>>> client
>>>> can't receive messages... I think is a specific GWT-RPC problem.
>>> Sorry for that. Can you send a test case (.war) that I can try? Which
>>> GlassFish or Grizzly version are you using?
>>>
>>> Thanks!
>>>
>>> -- Jeanfrancois
>>>
>>>> Thanks
>>>>
>>>> Marco
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[jewel_kader]

Hi Jeanfrancois,

Many thanks for your quick reply. I tried flushing comments before addCometHandler but it also seems not working.

In IE, flushing comments results com.google.gwt.user.client.rpc.InvocationException at client side immediately.

In FF, flushing comments does not comes to the client side immediately but it gets added with the first encoded response string sent from the server and eventually causes a error, since that comment makes the encoded response invalid.

I also tried flushing a empty string (zero length) instead of a comment but it also didn't work in IE though it prevented the Firefox's error.

I am new to grizzly and planning to write a online game server (Chess/Backgammon) using Grizzly and GWT but this IE error stopped everything. Can you please give me any other hints, so that I can try.

--Jewel

Jeanfrancois Arcand-2 wrote:

Salut,

jewel_kader wrote:
> Hi marcoflower,
>
> Does this long polling solution work in IE? I tried it in IE 6, 7, & 8. I
> got it not working in IE though no problem in Firefox.

I will eventually look at it (apology for that) :-( To help, can you
flush some comments like before invoking addCometHandler(..):

>         // for IE
>         writer.println("<!-- Comet is a programming technique that enables web servers to send data to the client without having any need for the client to request it. -->\n");
>         writer.flush();

I bet it will make it work. Keep me posted. If you can use Wireshark or
ngrep to snoop the network that would help me as well.

Thanks

-- Jeanfrancois


>
> Thanks
>
> Jewel
>
>
> marcoflower wrote:
>> You can find the .war here http://www.marcofiore.it/GrizzlyTest.war
>> I'm using GlassFishV2 and Grizzly 1.0.19
>>
>> Thanks
>>
>> Marco
>>
>>
>> Jeanfrancois Arcand-2 wrote:
>>> Salut,
>>>
>>> marcoflower wrote:
>>>>> Just never call resumeCometHandler. That will means the connection will
>>>>> stay suspended (streaming mode) forever.
>>>> I tried to remove the resumeCometHandler call, but if I remove it the
>>>> client
>>>> can't receive messages... I think is a specific GWT-RPC problem.
>>> Sorry for that. Can you send a test case (.war) that I can try? Which
>>> GlassFish or Grizzly version are you using?
>>>
>>> Thanks!
>>>
>>> -- Jeanfrancois
>>>
>>>> Thanks
>>>>
>>>> Marco
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [e-mail]
>>> For additional commands, e-mail: [e-mail]
>>>
>>>
>>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [e-mail]
For additional commands, e-mail: [e-mail]

[Amaury MYLONAS]

Hi,

it's just an idea but you could try to flush some kb of comments  
before. Some browsers like Safari requires some kb of data at the  
beginning of the stream to start the rendering.
And be sure you are not running some kind of service like Avast  
WebShield which is buffering a http stream before rendering it.

--
Amaury

Le 23 mars 09 à 15:51, jewel_kader a écrit :

>
> Hi Jeanfrancois,
>
> Many thanks for your quick reply. I tried flushing comments before
> addCometHandler but it also seems not working.
>
> In IE, flushing comments results
> com.google.gwt.user.client.rpc.InvocationException at client side
> immediately.
>
> In FF, flushing comments does not comes to the client side  
> immediately but
> it gets added with the first encoded response string sent from the  
> server
> and eventually causes a error, since that comment makes the encoded  
> response
> invalid.
>
> I also tried flushing a empty string (zero length) instead of a  
> comment but
> it also didn't work in IE though it prevented the Firefox's error.
>
> I am new to grizzly and planning to write a online game server
> (Chess/Backgammon) using Grizzly and GWT but this IE error stopped
> everything. Can you please give me any other hints, so that I can try.
>
> --Jewel
>
>
> Jeanfrancois Arcand-2 wrote:
>>
>> Salut,
>>
>> jewel_kader wrote:
>>> Hi marcoflower,
>>>
>>> Does this long polling solution work in IE? I tried it in IE 6, 7,  
>>> & 8. I
>>> got it not working in IE though no problem in Firefox.
>>
>> I will eventually look at it (apology for that) :-( To help, can you
>> flush some comments like before invoking addCometHandler(..):
>>
>>>        // for IE
>>>        writer.println("<!-- Comet is a programming technique that
>>> enables web servers to send data to the client without having any  
>>> need
>>> for the client to request it. -->\n");
>>>        writer.flush();
>>
>> I bet it will make it work. Keep me posted. If you can use  
>> Wireshark or
>> ngrep to snoop the network that would help me as well.
>>
>> Thanks
>>
>> -- Jeanfrancois
>>
>>
>>>
>>> Thanks
>>>
>>> Jewel
>>>
>>>
>>> marcoflower wrote:
>>>> You can find the .war here http://www.marcofiore.it/GrizzlyTest.war
>>>> I'm using GlassFishV2 and Grizzly 1.0.19
>>>>
>>>> Thanks
>>>>
>>>> Marco
>>>>
>>>>
>>>> Jeanfrancois Arcand-2 wrote:
>>>>> Salut,
>>>>>
>>>>> marcoflower wrote:
>>>>>>> Just never call resumeCometHandler. That will means the  
>>>>>>> connection
>>>>>>> will
>>>>>>> stay suspended (streaming mode) forever.
>>>>>> I tried to remove the resumeCometHandler call, but if I remove  
>>>>>> it the
>>>>>> client
>>>>>> can't receive messages... I think is a specific GWT-RPC problem.
>>>>> Sorry for that. Can you send a test case (.war) that I can try?  
>>>>> Which
>>>>> GlassFish or Grizzly version are you using?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> -- Jeanfrancois
>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Marco
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/GWT-%2B-Comet-question-%28was-Re%3A--Jean-Francois-Arcand%27s-Blog--New-Comment-Posted-to-%27Building-GWT-Comet-based-web-app-using-Grizzly-Comet%27-tp21416392p22661728.html
> Sent from the Grizzly - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[dun4n]

Hi,

it's just an idea but you could try to flush some kb of comments  
before. Some browsers like Safari requires some kb of data at the  
beginning of the stream to start the rendering.
And be sure you are not running some kind of service like Avast  
WebShield which is buffering a http stream before rendering it.

--
Amaury aka dun4n

Le 23 mars 09 à 15:51, jewel_kader a écrit :

>
> Hi Jeanfrancois,
>
> Many thanks for your quick reply. I tried flushing comments before
> addCometHandler but it also seems not working.
>
> In IE, flushing comments results
> com.google.gwt.user.client.rpc.InvocationException at client side
> immediately.
>
> In FF, flushing comments does not comes to the client side  
> immediately but
> it gets added with the first encoded response string sent from the  
> server
> and eventually causes a error, since that comment makes the encoded  
> response
> invalid.
>
> I also tried flushing a empty string (zero length) instead of a  
> comment but
> it also didn't work in IE though it prevented the Firefox's error.
>
> I am new to grizzly and planning to write a online game server
> (Chess/Backgammon) using Grizzly and GWT but this IE error stopped
> everything. Can you please give me any other hints, so that I can try.
>
> --Jewel
>
>
> Jeanfrancois Arcand-2 wrote:
>>
>> Salut,
>>
>> jewel_kader wrote:
>>> Hi marcoflower,
>>>
>>> Does this long polling solution work in IE? I tried it in IE 6, 7,  
>>> & 8. I
>>> got it not working in IE though no problem in Firefox.
>>
>> I will eventually look at it (apology for that) :-( To help, can you
>> flush some comments like before invoking addCometHandler(..):
>>
>>>        // for IE
>>>        writer.println("<!-- Comet is a programming technique that
>>> enables web servers to send data to the client without having any  
>>> need
>>> for the client to request it. -->\n");
>>>        writer.flush();
>>
>> I bet it will make it work. Keep me posted. If you can use  
>> Wireshark or
>> ngrep to snoop the network that would help me as well.
>>
>> Thanks
>>
>> -- Jeanfrancois
>>
>>
>>>
>>> Thanks
>>>
>>> Jewel
>>>
>>>
>>> marcoflower wrote:
>>>> You can find the .war here http://www.marcofiore.it/GrizzlyTest.war
>>>> I'm using GlassFishV2 and Grizzly 1.0.19
>>>>
>>>> Thanks
>>>>
>>>> Marco
>>>>
>>>>
>>>> Jeanfrancois Arcand-2 wrote:
>>>>> Salut,
>>>>>
>>>>> marcoflower wrote:
>>>>>>> Just never call resumeCometHandler. That will means the  
>>>>>>> connection
>>>>>>> will
>>>>>>> stay suspended (streaming mode) forever.
>>>>>> I tried to remove the resumeCometHandler call, but if I remove  
>>>>>> it the
>>>>>> client
>>>>>> can't receive messages... I think is a specific GWT-RPC problem.
>>>>> Sorry for that. Can you send a test case (.war) that I can try?  
>>>>> Which
>>>>> GlassFish or Grizzly version are you using?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> -- Jeanfrancois
>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Marco
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/GWT-%2B-Comet-question-%28was-Re%3A--Jean-Francois-Arcand%27s-Blog--New-Comment-Posted-to-%27Building-GWT-Comet-based-web-app-using-Grizzly-Comet%27-tp21416392p22661728.html
> Sent from the Grizzly - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jeanfrancois Arcand-2]

Salut,

dun4n wrote:
> Hi,
>
> it's just an idea but you could try to flush some kb of comments before.
> Some browsers like Safari requires some kb of data at the beginning of
> the stream to start the rendering.
> And be sure you are not running some kind of service like Avast
> WebShield which is buffering a http stream before rendering it.

Yes the comet-jmaki demo seemed to work when flushing some bytes before
suspending the connection. I don't have a win32 machine available this
week but I do think this is related.

A+

- Jeanfrancois


>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[jewel_kader]

Hi,

In IE, flushing a comment causes a com.google.gwt.user.client.rpc.InvocationException at the client side. However writing something that GWT understand works. For example, instead of writing a comment before calling addCometHandler, I flushed "//OK[2,1,[\"com.game.chess.client.Message/483634159\",\"123\"],0,5]", which is a encoded response string in gwt way.

This process suspends the response successfully but on comet event, when I tried to send my own data, only the previously written (flushed before addCometHandler) data came to the client.

Thanks,

--Jewel

Jeanfrancois Arcand-2 wrote:

Salut,

dun4n wrote:
> Hi,
>
> it's just an idea but you could try to flush some kb of comments before.
> Some browsers like Safari requires some kb of data at the beginning of
> the stream to start the rendering.
> And be sure you are not running some kind of service like Avast
> WebShield which is buffering a http stream before rendering it.

Yes the comet-jmaki demo seemed to work when flushing some bytes before
suspending the connection. I don't have a win32 machine available this
week but I do think this is related.

A+

- Jeanfrancois


>

---------------------------------------------------------------------
To unsubscribe, e-mail: [e-mail]
For additional commands, e-mail: [e-mail]

[Jeanfrancois Arcand-2]

Salut,

jewel_kader wrote:

> Hi,
>
> In IE, flushing a comment causes a
> com.google.gwt.user.client.rpc.InvocationException at the client side.
> However writing something that GWT understand works. For example, instead of
> writing a comment before calling addCometHandler, I flushed
> "//OK[2,1,[\"com.game.chess.client.Message/483634159\",\"123\"],0,5]", which
> is a encoded response string in gwt way.
>
> This process suspends the response successfully but on comet event, when I
> tried to send my own data, only the previously written (flushed before
> addCometHandler) data came to the client.

Ok making progress. I'm on the road and don't have IE availble so trying
to help. Can you invoke the HttpResponse.getWriter().flush() everytime
you write something? Also, do you think you can install
ngrep.sourceforge.net or wireshark and snoop the network to see if the
bytes are sent to the browser?

Apology for not being able to help here more...no IE on Ubuntu/OS X :-)

A+

-- Jeanfrancois

>
> Thanks,
>
> --Jewel
>
>
> Jeanfrancois Arcand-2 wrote:
>> Salut,
>>
>> dun4n wrote:
>>> Hi,
>>>
>>> it's just an idea but you could try to flush some kb of comments before.
>>> Some browsers like Safari requires some kb of data at the beginning of
>>> the stream to start the rendering.
>>> And be sure you are not running some kind of service like Avast
>>> WebShield which is buffering a http stream before rendering it.
>> Yes the comet-jmaki demo seemed to work when flushing some bytes before
>> suspending the connection. I don't have a win32 machine available this
>> week but I do think this is related.
>>
>> A+
>>
>> - Jeanfrancois
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[jewel_kader]

Hi Jeanfrancois,

In my example I used new PrintWriter(HttpResponse.getOutputStream()).flush(). I also tried HttpResponse.getWriter().flush() but this made no change.

Right now, I am writing a pub/sub pattern based wrapper on top of Grizzly and GWT. Grizzly at least can suspend a connection of IE and notify the client in future. Though it can't propagate right the message, I guess based on that I have to write a different adapter for IE to send the right message to the client.

I downloaded ngrep.sourceforge.net, wireshark. Unfortunately, I am not so familiar with those. I will let you know if I make any progress.

Many thanks for you help.

--Jewel

Jeanfrancois Arcand-2 wrote:

Salut,

jewel_kader wrote:
> Hi,
>
> In IE, flushing a comment causes a
> com.google.gwt.user.client.rpc.InvocationException at the client side.
> However writing something that GWT understand works. For example, instead of
> writing a comment before calling addCometHandler, I flushed
> "//OK[2,1,[\"com.game.chess.client.Message/483634159\",\"123\"],0,5]", which
> is a encoded response string in gwt way.
>
> This process suspends the response successfully but on comet event, when I
> tried to send my own data, only the previously written (flushed before
> addCometHandler) data came to the client.

Ok making progress. I'm on the road and don't have IE availble so trying
to help. Can you invoke the HttpResponse.getWriter().flush() everytime
you write something? Also, do you think you can install
ngrep.sourceforge.net or wireshark and snoop the network to see if the
bytes are sent to the browser?

Apology for not being able to help here more...no IE on Ubuntu/OS X :-)

A+

-- Jeanfrancois

>
> Thanks,
>
> --Jewel
>
>
> Jeanfrancois Arcand-2 wrote:
>> Salut,
>>
>> dun4n wrote:
>>> Hi,
>>>
>>> it's just an idea but you could try to flush some kb of comments before.
>>> Some browsers like Safari requires some kb of data at the beginning of
>>> the stream to start the rendering.
>>> And be sure you are not running some kind of service like Avast
>>> WebShield which is buffering a http stream before rendering it.
>> Yes the comet-jmaki demo seemed to work when flushing some bytes before
>> suspending the connection. I don't have a win32 machine available this
>> week but I do think this is related.
>>
>> A+
>>
>> - Jeanfrancois
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [e-mail]
>> For additional commands, e-mail: [e-mail]
>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [e-mail]
For additional commands, e-mail: [e-mail]

[jewel_kader]

Hi Jeanfrancois,

Long polling seems to work in IE after doing a trick.

Flushing a arbitrary string or a comment causes a error in GWT's RPC system. Flushing something like "//OK[2,1,[\"com.game.chess.client.Message/483634159\",\"123\"],0,5]" (which GWT understand) before suspending the connection, prevents the error. However this flushed data don't came to the browser immediately. Rather, onEvent sending another data ("//OK[2,1,[\"com.game.chess.client.Message/483634159\",\"456\"],0,5]") and resuming the handler, results reaching the data at the client side. However, the GWT client seems to care only the first part of the data and discard the original (2nd) part.

So I flushed a part of the String ("//OK") at first and onEvent wrote rest of the encoded string ("[2,1,[\"com.game.chess.client.Message/483634159\",\"456\"],0,5]") and this seems to work in IE and FF. GWT's RPC is also happy.

Thanks,

--Jewel



Hi Jeanfrancois,

In my example I used new PrintWriter(HttpResponse.getOutputStream()).flush(). I also tried HttpResponse.getWriter().flush() but this made no change.

Right now, I am writing a pub/sub pattern based wrapper on top of Grizzly and GWT. Grizzly at least can suspend a connection of IE and notify the client in future. Though it can't propagate right the message, I guess based on that I have to write a different adapter for IE to send the right message to the client.

I downloaded ngrep.sourceforge.net, wireshark. Unfortunately, I am not so familiar with those. I will let you know if I make any progress.

Many thanks for you help.

--Jewel

Jeanfrancois Arcand-2 wrote:

Salut,

jewel_kader wrote:
> Hi,
>
> In IE, flushing a comment causes a
> com.google.gwt.user.client.rpc.InvocationException at the client side.
> However writing something that GWT understand works. For example, instead of
> writing a comment before calling addCometHandler, I flushed
> "//OK[2,1,[\"com.game.chess.client.Message/483634159\",\"123\"],0,5]", which
> is a encoded response string in gwt way.
>
> This process suspends the response successfully but on comet event, when I
> tried to send my own data, only the previously written (flushed before
> addCometHandler) data came to the client.

Ok making progress. I'm on the road and don't have IE availble so trying
to help. Can you invoke the HttpResponse.getWriter().flush() everytime
you write something? Also, do you think you can install
ngrep.sourceforge.net or wireshark and snoop the network to see if the
bytes are sent to the browser?

Apology for not being able to help here more...no IE on Ubuntu/OS X :-)

A+

-- Jeanfrancois

>
> Thanks,
>
> --Jewel
>
>
> Jeanfrancois Arcand-2 wrote:
>> Salut,
>>
>> dun4n wrote:
>>> Hi,
>>>
>>> it's just an idea but you could try to flush some kb of comments before.
>>> Some browsers like Safari requires some kb of data at the beginning of
>>> the stream to start the rendering.
>>> And be sure you are not running some kind of service like Avast
>>> WebShield which is buffering a http stream before rendering it.
>> Yes the comet-jmaki demo seemed to work when flushing some bytes before
>> suspending the connection. I don't have a win32 machine available this
>> week but I do think this is related.
>>
>> A+
>>
>> - Jeanfrancois
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [e-mail]
>> For additional commands, e-mail: [e-mail]
>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [e-mail]
For additional commands, e-mail: [e-mail]

[Jeanfrancois Arcand-2]

Salut,

jewel_kader wrote:

> Hi Jeanfrancois,
>
> Long polling seems to work in IE after doing a trick.
>
> Flushing a arbitrary string or a comment causes a error in GWT's RPC system.
> Flushing something like
> "//OK[2,1,[\"com.game.chess.client.Message/483634159\",\"123\"],0,5]" (which
> GWT understand) before suspending the connection, prevents the error.
> However this flushed data don't came to the browser immediately. Rather,
> onEvent sending another data
> ("//OK[2,1,[\"com.game.chess.client.Message/483634159\",\"456\"],0,5]") and
> resuming the handler, results reaching the data at the client side. However,
> the GWT client seems to care only the first part of the data and discard the
> original (2nd) part.
>
> So I flushed a part of the String ("//OK") at first and onEvent wrote rest
> of the encoded string
> ("[2,1,[\"com.game.chess.client.Message/483634159\",\"456\"],0,5]") and this
> seems to work in IE and FF. GWT's RPC is also happy.

This is great. Are you planning to blog about this :-) ?

Let us know if you have any more issues. Hopefully I reply faster once
ApacheCon is finished.

A+

--Jeanfrancois

>
> Thanks,
>
> --Jewel
>
>
>
> jewel_kader wrote:
>> Hi Jeanfrancois,
>>
>> In my example I used new
>> PrintWriter(HttpResponse.getOutputStream()).flush(). I also tried
>> HttpResponse.getWriter().flush() but this made no change.
>>
>> Right now, I am writing a pub/sub pattern based wrapper on top of Grizzly
>> and GWT. Grizzly at least can suspend a connection of IE and notify the
>> client in future. Though it can't propagate right the message, I guess
>> based on that I have to write a different adapter for IE to send the right
>> message to the client.
>>
>> I downloaded ngrep.sourceforge.net, wireshark. Unfortunately, I am not so
>> familiar with those. I will let you know if I make any progress.
>>
>> Many thanks for you help.
>>
>> --Jewel
>>
>>
>> Jeanfrancois Arcand-2 wrote:
>>> Salut,
>>>
>>> jewel_kader wrote:
>>>> Hi,
>>>>
>>>> In IE, flushing a comment causes a
>>>> com.google.gwt.user.client.rpc.InvocationException at the client side.
>>>> However writing something that GWT understand works. For example,
>>>> instead of
>>>> writing a comment before calling addCometHandler, I flushed
>>>> "//OK[2,1,[\"com.game.chess.client.Message/483634159\",\"123\"],0,5]",
>>>> which
>>>> is a encoded response string in gwt way.
>>>>
>>>> This process suspends the response successfully but on comet event, when
>>>> I
>>>> tried to send my own data, only the previously written (flushed before
>>>> addCometHandler) data came to the client.
>>> Ok making progress. I'm on the road and don't have IE availble so trying
>>> to help. Can you invoke the HttpResponse.getWriter().flush() everytime
>>> you write something? Also, do you think you can install
>>> ngrep.sourceforge.net or wireshark and snoop the network to see if the
>>> bytes are sent to the browser?
>>>
>>> Apology for not being able to help here more...no IE on Ubuntu/OS X :-)
>>>
>>> A+
>>>
>>> -- Jeanfrancois
>>>
>>>> Thanks,
>>>>
>>>> --Jewel
>>>>
>>>>
>>>> Jeanfrancois Arcand-2 wrote:
>>>>> Salut,
>>>>>
>>>>> dun4n wrote:
>>>>>> Hi,
>>>>>>
>>>>>> it's just an idea but you could try to flush some kb of comments
>>>>>> before.
>>>>>> Some browsers like Safari requires some kb of data at the beginning of
>>>>>> the stream to start the rendering.
>>>>>> And be sure you are not running some kind of service like Avast
>>>>>> WebShield which is buffering a http stream before rendering it.
>>>>> Yes the comet-jmaki demo seemed to work when flushing some bytes before
>>>>> suspending the connection. I don't have a win32 machine available this
>>>>> week but I do think this is related.
>>>>>
>>>>> A+
>>>>>
>>>>> - Jeanfrancois
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[jewel_kader]

Hi Jeanfrancois,

Since I am using GWT and Grizzly in a project, I eventually have to write something that works in real application. I am planning to publish the comet related code under a open source project. So that other people can take a look and let us know, if there is something wrong.

Many thanks for your help.

--Jewel

Jeanfrancois Arcand-2 wrote:

Salut,

jewel_kader wrote:
> Hi Jeanfrancois,
>
> Long polling seems to work in IE after doing a trick.
>
> Flushing a arbitrary string or a comment causes a error in GWT's RPC system.
> Flushing something like
> "//OK[2,1,[\"com.game.chess.client.Message/483634159\",\"123\"],0,5]" (which
> GWT understand) before suspending the connection, prevents the error.
> However this flushed data don't came to the browser immediately. Rather,
> onEvent sending another data
> ("//OK[2,1,[\"com.game.chess.client.Message/483634159\",\"456\"],0,5]") and
> resuming the handler, results reaching the data at the client side. However,
> the GWT client seems to care only the first part of the data and discard the
> original (2nd) part.
>
> So I flushed a part of the String ("//OK") at first and onEvent wrote rest
> of the encoded string
> ("[2,1,[\"com.game.chess.client.Message/483634159\",\"456\"],0,5]") and this
> seems to work in IE and FF. GWT's RPC is also happy.

This is great. Are you planning to blog about this :-) ?

Let us know if you have any more issues. Hopefully I reply faster once
ApacheCon is finished.

A+

--Jeanfrancois


>
> Thanks,
>
> --Jewel
>
>
>
> jewel_kader wrote:
>> Hi Jeanfrancois,
>>
>> In my example I used new
>> PrintWriter(HttpResponse.getOutputStream()).flush(). I also tried
>> HttpResponse.getWriter().flush() but this made no change.
>>
>> Right now, I am writing a pub/sub pattern based wrapper on top of Grizzly
>> and GWT. Grizzly at least can suspend a connection of IE and notify the
>> client in future. Though it can't propagate right the message, I guess
>> based on that I have to write a different adapter for IE to send the right
>> message to the client.
>>
>> I downloaded ngrep.sourceforge.net, wireshark. Unfortunately, I am not so
>> familiar with those. I will let you know if I make any progress.
>>
>> Many thanks for you help.
>>
>> --Jewel
>>
>>
>> Jeanfrancois Arcand-2 wrote:
>>> Salut,
>>>
>>> jewel_kader wrote:
>>>> Hi,
>>>>
>>>> In IE, flushing a comment causes a
>>>> com.google.gwt.user.client.rpc.InvocationException at the client side.
>>>> However writing something that GWT understand works. For example,
>>>> instead of
>>>> writing a comment before calling addCometHandler, I flushed
>>>> "//OK[2,1,[\"com.game.chess.client.Message/483634159\",\"123\"],0,5]",
>>>> which
>>>> is a encoded response string in gwt way.
>>>>
>>>> This process suspends the response successfully but on comet event, when
>>>> I
>>>> tried to send my own data, only the previously written (flushed before
>>>> addCometHandler) data came to the client.
>>> Ok making progress. I'm on the road and don't have IE availble so trying
>>> to help. Can you invoke the HttpResponse.getWriter().flush() everytime
>>> you write something? Also, do you think you can install
>>> ngrep.sourceforge.net or wireshark and snoop the network to see if the
>>> bytes are sent to the browser?
>>>
>>> Apology for not being able to help here more...no IE on Ubuntu/OS X :-)
>>>
>>> A+
>>>
>>> -- Jeanfrancois
>>>
>>>> Thanks,
>>>>
>>>> --Jewel
>>>>
>>>>
>>>> Jeanfrancois Arcand-2 wrote:
>>>>> Salut,
>>>>>
>>>>> dun4n wrote:
>>>>>> Hi,
>>>>>>
>>>>>> it's just an idea but you could try to flush some kb of comments
>>>>>> before.
>>>>>> Some browsers like Safari requires some kb of data at the beginning of
>>>>>> the stream to start the rendering.
>>>>>> And be sure you are not running some kind of service like Avast
>>>>>> WebShield which is buffering a http stream before rendering it.
>>>>> Yes the comet-jmaki demo seemed to work when flushing some bytes before
>>>>> suspending the connection. I don't have a win32 machine available this
>>>>> week but I do think this is related.
>>>>>
>>>>> A+
>>>>>
>>>>> - Jeanfrancois
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [e-mail]
>>>>> For additional commands, e-mail: [e-mail]
>>>>>
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [e-mail]
>>> For additional commands, e-mail: [e-mail]
>>>
>>>
>>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [e-mail]
For additional commands, e-mail: [e-mail]