RF 4.5.x: too many push messages will be skipped

[dako_t]

Hi all,

I'am using RF 4.5.9 and the push component. The messages will fired from a CDI-Bean in this way:

TopicsContext topicsContext = TopicsContext.lookup();
TopicKey updateKey = new TopicKey("pushTest", "test1");
topicsContext.publish(updateKey, "myMessage");

But if the messages will be fired too fast, a lot of messages seems to be skipped. This means not alle fired messages are consumed by the push component. For example if I fire 15 messages in a for loop without a delay, just three messages are processed by the push component. If I put a Thread.sleep(50) before invoking the publish method, all messages will be processed by the push component.

What can I do to ensure that all messages will be consumed by the push component? "Thread.sleep" looks very dirty.

Best regards

[dako_t]

Hi all,

ok I have found out, that the JavaScript function which is set in ondataavailable will be invoked every time. For example:

<a4j:push id="pushTest" address="test1@pushTest" ondataavailable="updateValues(event.rf.data);" />

But in the JavaScript function "updateValues" an other JavaScript function will be invoked and thia JavaScript function is created by:

<a4j:jsFunction name="pushUpdate" action="#{pushTestController.preparePushUpdate}"...

My proble is, that the action method will not invoked every time.

[michpetrov]

JSF can only process requests one by one so we have a queue in place. What happens is that the first request is sent to the server and the queue waits for a response to come and only then fires another request, in the meantime incoming requests are ignored (because they look similar to the one that's in the queue).

I don't really understand the use-case - you're generating messages on the server, sending them to the client using push and then the client calls the server via an Ajax request, why? Also if you expect a real situation where many messages will be generated at once maybe merge them on the server to begin with?

(Unfortunately I'm not going to be able to reply the next week.)

[dako_t]

Hi Michal,

the functional use case:

We have a view with a lot of input and select fields for container ship data. Several users working on the same ship and changing data. If user one change something, all other users wants to see the changes. The push event should rerender only the element which was changed.

The technical workflow (simplified):

1. a global application scoped CDI bean sends a String with a JSon object to all clients which have the given push component, via topicsContext.publish ...

2. The push component sends the JSon object via the action attribute of an a4j:jsFunction to the server, e.g. action="#{pushTestController.updateAttribute}"

3. The a4j:jsFunction has an attribute render which contains a list of strings, e.g. render="#{pushTestController.ids2ReRender}"

4. The backing CDI bean in window scope which invokes the method "updateAttribute" gets an entity from DB and sets it to the backing bean.

5. Afterwards the action method sets all ids to rerender into the list "ids2ReRender"

6. The a4j:jsFunction rerenders all ids on the xhtml page with the new values from the backing bean

That works fine, except the messages comes too fast.

I assume that I have to implement a JavaScript Queue which processes all push objects step by step. Process the first entry wait for the response from the server and then process the next entry, wait for the response and so on.

What do you think about this solution?

[dako_t]

Hi Mihal,

I have implemented a JavaScript-Queue which processes all entries step by step. It works fine.

[michpetrov]

Well, glad it works though I still don't understand what you're doing - bean on a server sends data to client, client sends the data back to server; why don't you have the bean send the data directly to the other bean?

[dako_t]

How would you send an object to several cdi beans in windowscope(deltaspike)? With jms? Push events are a good way to send a json string to all open pages. Afterwards you can process the json object on the server.

nevertheles if your bean is updated and you sends just an push event to the page, you have to rerender a part of the page via an a4j:ajax listener. This needs a server request, hence it's the same issue. You can test it, send 150 push events in a for loop to a page, not all rerender listener will be correct processed.

[michpetrov]

There is injection for one, or events/observers. Point is the data is already on the server and it needs to go to another place on the server, going through the client is an unnecessary detour.

As far as rerender goes you should use it only if you need to fetch data from the server, since the server is sending the data to the client you should handle it on the client side (e.g. create HTML fragments with jQuery and insert them into the page). Otherwise you wouldn't need push, you could use something like a4j:poll to refresh the page periodically.

[dako_t]

I want to go the jsf way, it doesnt matters if I use push or poll. Updating the page with jqery only would be possible but it would be a break in the use of the existing jsf components. For input fields it would be easy, but for table components it's easier to go my way. Even if we have one or two requests more than with a pure client solution.