Forum OpenACS Development: Re: Toughts on an Event Engine

Collapse
19: Re: Toughts on an Event Engine (response to 18)
Posted by Gustaf Neumann on 02/17/13 01:01 PM
Dear Antonio,

Many thanks for testing and providing the changes, which are merged now into CVS head [1]. Please double-check, if everything is still fine. I have some mixed feelings about making the streaming versions default. The check for the browsers applies just for current versions (older versions behave differently), and streaming behavior might be influenced by a reverse proxy.

However, i have left streaming defaults as in your patch and added a longer comment session to the chat-procs with some warnings. This way, for streaming works immediately for people who want to try out COMET streaming without much hassle, and people working with large production sites know their requirements and will pass the appropriate "-mode " flag to Chat.

Many thanks and best regards
-gustaf neumann

[1] http://cvs.openacs.org/changelog/OpenACS?cs=MAIN%3Agustafn%3A20130217114806

Collapse
20: Re: Toughts on an Event Engine (response to 19)
Posted by Antonio Pisano on 02/18/13 07:17 PM
Commit seems fine to me, the comment is very explicit and explains clearly how to choose the right method.

That said, I have some more modifications which I would like to expose and discuss with you:

in these days I managed to implement notifications on my portal using your Comet chat. It works like this: the master template included in every page calls the login on the chat, then waits for any message to occour (messages are sent by other pages).

The normal workflow of my users (the portal is an ERP) causes many and many calls of the login method, as there is little to no use of ajax and the master template is always called. Every time the chat logs in it opens a new channel.

After some hours this took to the reach of the 1000 file handles you were talking about and to a reboot of the server.

I dug some more into the code: when a message is sent to the subscribers, it is checked wether the channel is still alive, and if it's not it is closed. This works good in a proper chat, where messages are sent quite often. In my situation tough, this happens only seldom, as the notified events are not frequent, so dead channels are never cleaned.

I created a new method in the Subscriber class of bgdelivery, which takes care of cleaning dead channels every time someone subscribes. Similar methods exist for other objects in the bgdelivery, and seems like this solved the issue.

Also, I was not super happy about my previous change in the bgdeliveries-procs: after setting the content type to octet stream, the encoding of the characters had to be solved on the client side, causing extra effort to the end user. I found out I could just use the "encoding" command to translate the message server side, avoiding to use "escape" on the client.

I changed the chat page in xowiki too, only to allow the sending of messages containing html. If I don't allow it, it is impossible to send even the char "<", and it should be safe, because we already quote all the html in the message on the server.

I updated the zip file I linked to include the modifications I am talking about. The bgdelivery-procs file had been checked against your last cvs commit.

Let me know if it could be ok for you.

Best regards

Antonio