Broadcast message state

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Broadcast message state

Koen Serneels-2
Hello,

Supose I have one producer and one consumer.
I use Atmosphere and Jersey to build a long-polling solution that returns data to the consumer from the moment the producer published something.
So I have a basic broadcast/suspend, where the producer does a POST, triggering a resume on the consumers GET.
(this is in line with the atmosphere pub/sub sampe)

Lets assume that the information received by the consumer is shown in a html table.
The table should always contain the complete history of the communication.
Each 'post' of the producer represents a single row in the consumers HTML table.
So if the procuder produced 10events, we'll have 10 rows in the table.

I don't know what the best practise is here, but I supose that in the case of streaming the reponse is "always complete".
In that sense that it alway contains the information for table published upon that time by the producer.
In that case I can replace the table with the content of the response, since it wil always contains the history.
In case of long polling I would have to explicitly remember the history on the server side and send the complete trace along with each reply.

Now, supose I do long polling but I only want to sent the newly published data along and not the old data.
In other words, the old data is displayed on the html table, and the new data should simply be added.
In that case my HTML table on the client side is acting as history state, and new data is added as a new row.

In that case I could have the scenario where the consumer gets data back, connection is closed, but before the consumer reconnets, the producer broadcasts new data.
This means that (at least by default) my consumer will not get any notification when it reconnects:

1. Producer sends data A
2. Resume consumer connection + close connection
3. Consumer adds extra row in html table
4. Producer sends data B
<consumer is not connected, so does not get a notification>
5. Consumer reconnects and suspends connection

---> data B is "lost" and was not displayed.

Is there a way to solve this issue?

Thanks

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Broadcast message state

Cunha
Hi Koen,

I'm also facing the same problem as you are, in my case I built a notification protocol using atmosphere, but since I persist all notification on a database, I'm able to return notifications that were lost during client the re-connection process  using a last received id. But I would also like to know if Atmosphere supports this on a native way. 


On Mon, Jul 18, 2011 at 1:40 PM, Koen Serneels <[hidden email]> wrote:
Hello,

Supose I have one producer and one consumer.
I use Atmosphere and Jersey to build a long-polling solution that returns data to the consumer from the moment the producer published something.
So I have a basic broadcast/suspend, where the producer does a POST, triggering a resume on the consumers GET.
(this is in line with the atmosphere pub/sub sampe)

Lets assume that the information received by the consumer is shown in a html table.
The table should always contain the complete history of the communication.
Each 'post' of the producer represents a single row in the consumers HTML table.
So if the procuder produced 10events, we'll have 10 rows in the table.

I don't know what the best practise is here, but I supose that in the case of streaming the reponse is "always complete".
In that sense that it alway contains the information for table published upon that time by the producer.
In that case I can replace the table with the content of the response, since it wil always contains the history.
In case of long polling I would have to explicitly remember the history on the server side and send the complete trace along with each reply.

Now, supose I do long polling but I only want to sent the newly published data along and not the old data.
In other words, the old data is displayed on the html table, and the new data should simply be added.
In that case my HTML table on the client side is acting as history state, and new data is added as a new row.

In that case I could have the scenario where the consumer gets data back, connection is closed, but before the consumer reconnets, the producer broadcasts new data.
This means that (at least by default) my consumer will not get any notification when it reconnects:

1. Producer sends data A
2. Resume consumer connection + close connection
3. Consumer adds extra row in html table
4. Producer sends data B
<consumer is not connected, so does not get a notification>
5. Consumer reconnects and suspends connection

---> data B is "lost" and was not displayed.

Is there a way to solve this issue?

Thanks


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Broadcast message state

java.net
Hi,

Have a look at the different implementations of BroadcasterCache http://is.gd/0WoPBV

Pierre

On Mon, Jul 18, 2011 at 2:59 PM, João Cunha <[hidden email]> wrote:
Hi Koen,

I'm also facing the same problem as you are, in my case I built a notification protocol using atmosphere, but since I persist all notification on a database, I'm able to return notifications that were lost during client the re-connection process  using a last received id. But I would also like to know if Atmosphere supports this on a native way. 


On Mon, Jul 18, 2011 at 1:40 PM, Koen Serneels <[hidden email]> wrote:
Hello,

Supose I have one producer and one consumer.
I use Atmosphere and Jersey to build a long-polling solution that returns data to the consumer from the moment the producer published something.
So I have a basic broadcast/suspend, where the producer does a POST, triggering a resume on the consumers GET.
(this is in line with the atmosphere pub/sub sampe)

Lets assume that the information received by the consumer is shown in a html table.
The table should always contain the complete history of the communication.
Each 'post' of the producer represents a single row in the consumers HTML table.
So if the procuder produced 10events, we'll have 10 rows in the table.

I don't know what the best practise is here, but I supose that in the case of streaming the reponse is "always complete".
In that sense that it alway contains the information for table published upon that time by the producer.
In that case I can replace the table with the content of the response, since it wil always contains the history.
In case of long polling I would have to explicitly remember the history on the server side and send the complete trace along with each reply.

Now, supose I do long polling but I only want to sent the newly published data along and not the old data.
In other words, the old data is displayed on the html table, and the new data should simply be added.
In that case my HTML table on the client side is acting as history state, and new data is added as a new row.

In that case I could have the scenario where the consumer gets data back, connection is closed, but before the consumer reconnets, the producer broadcasts new data.
This means that (at least by default) my consumer will not get any notification when it reconnects:

1. Producer sends data A
2. Resume consumer connection + close connection
3. Consumer adds extra row in html table
4. Producer sends data B
<consumer is not connected, so does not get a notification>
5. Consumer reconnects and suspends connection

---> data B is "lost" and was not displayed.

Is there a way to solve this issue?

Thanks



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Broadcast message state

Jeanfrancois Arcand-4
In reply to this post by Koen Serneels-2
Salut,

On 11-07-18 8:40 AM, Koen Serneels wrote:

> Hello,
>
> Supose I have one producer and one consumer.
> I use Atmosphere and Jersey to build a long-polling solution that
> returns data to the consumer from the moment the producer published
> something.
> So I have a basic broadcast/suspend, where the producer does a POST,
> triggering a resume on the consumers GET.
> (this is in line with the atmosphere pub/sub sampe)
>
> Lets assume that the information received by the consumer is shown in a
> html table.
> The table should always contain the complete history of the communication.
> Each 'post' of the producer represents a single row in the consumers
> HTML table.
> So if the procuder produced 10events, we'll have 10 rows in the table.
>
> I don't know what the best practise is here, but I supose that in the
> case of streaming the reponse is "always complete".
> In that sense that it alway contains the information for table published
> upon that time by the producer.
> In that case I can replace the table with the content of the response,
> since it wil always contains the history.
> In case of long polling I would have to explicitly remember the history
> on the server side and send the complete trace along with each reply.
>
> Now, supose I do long polling but I only want to sent the newly
> published data along and not the old data.
> In other words, the old data is displayed on the html table, and the new
> data should simply be added.
> In that case my HTML table on the client side is acting as history
> state, and new data is added as a new row.
>
> In that case I could have the scenario where the consumer gets data
> back, connection is closed, but before the consumer reconnets, the
> producer broadcasts new data.
> This means that (at least by default) my consumer will not get any
> notification when it reconnects:
>
> 1. Producer sends data A
> 2. Resume consumer connection + close connection
> 3. Consumer adds extra row in html table
> 4. Producer sends data B
> <consumer is not connected, so does not get a notification>
> 5. Consumer reconnects and suspends connection
>
> ---> data B is "lost" and was not displayed.
>
> Is there a way to solve this issue?

yes, take a look at the BroadcasterCache concept:

> http://jfarcand.wordpress.com/2010/07/02/fridays-trick-2-websocketcomet-survival-guide-to-proxy-firewall-and-network-outage/

Right now we support the concept using the http session or a special
header/time stamp. Let me know how it goes.

A+

-- Jeanfrancois



>
> Thanks
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Broadcast message state

Jeanfrancois Arcand-4
In reply to this post by Cunha
Salut,

take a look at:

> http://jfarcand.wordpress.com/2010/07/02/fridays-trick-2-websocketcomet-survival-guide-to-proxy-firewall-and-network-outage/

Also note that you can write your own implementation to customize the
behavior.

A+

--Jeanfrancois

On 11-07-18 8:59 AM, João Cunha wrote:

> Hi Koen,
>
> I'm also facing the same problem as you are, in my case I built a
> notification protocol using atmosphere, but since I persist all
> notification on a database, I'm able to return notifications that were
> lost during client the re-connection process  using a last received id.
> But I would also like to know if Atmosphere supports this on a native way.
>
>
> On Mon, Jul 18, 2011 at 1:40 PM, Koen Serneels <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hello,
>
>     Supose I have one producer and one consumer.
>     I use Atmosphere and Jersey to build a long-polling solution that
>     returns data to the consumer from the moment the producer published
>     something.
>     So I have a basic broadcast/suspend, where the producer does a POST,
>     triggering a resume on the consumers GET.
>     (this is in line with the atmosphere pub/sub sampe)
>
>     Lets assume that the information received by the consumer is shown
>     in a html table.
>     The table should always contain the complete history of the
>     communication.
>     Each 'post' of the producer represents a single row in the consumers
>     HTML table.
>     So if the procuder produced 10events, we'll have 10 rows in the table.
>
>     I don't know what the best practise is here, but I supose that in
>     the case of streaming the reponse is "always complete".
>     In that sense that it alway contains the information for table
>     published upon that time by the producer.
>     In that case I can replace the table with the content of the
>     response, since it wil always contains the history.
>     In case of long polling I would have to explicitly remember the
>     history on the server side and send the complete trace along with
>     each reply.
>
>     Now, supose I do long polling but I only want to sent the newly
>     published data along and not the old data.
>     In other words, the old data is displayed on the html table, and the
>     new data should simply be added.
>     In that case my HTML table on the client side is acting as history
>     state, and new data is added as a new row.
>
>     In that case I could have the scenario where the consumer gets data
>     back, connection is closed, but before the consumer reconnets, the
>     producer broadcasts new data.
>     This means that (at least by default) my consumer will not get any
>     notification when it reconnects:
>
>     1. Producer sends data A
>     2. Resume consumer connection + close connection
>     3. Consumer adds extra row in html table
>     4. Producer sends data B
>     <consumer is not connected, so does not get a notification>
>     5. Consumer reconnects and suspends connection
>
>     ---> data B is "lost" and was not displayed.
>
>     Is there a way to solve this issue?
>
>     Thanks
>
>
Loading...