tigerlily/redisse

Redisse – Redis-backed Server-Sent Events

redisse's Issues

Heartbeat timer never stops

Even when the client has disconnected, the heartbeat EM periodic timer will keep running.

Document Redisse#test_mode!

Server crashes with some values of lastEventId

Repro:

• lastEventId is a number so it triggers handling history events
• lastEventId is large enough that no history events need to be sent (e.g. it's larger than the last event id sent by the server)

With a clean Redis db, this is enough to crash the server:

$ curl localhost:4242/events?lastEventId=42 --header 'Accept: text/event-stream'

Binary for server

Right now we require to create a server object (that extends Redisse), configure it and write a server binary using that object (cf. usage section of the README).
We could let people configure Redisse directly and provide the binary instead.

Use Redis scripts

For publishing and fetching history, instead of sending several Redis commands, we could use Redis scripts

lastEventId event

A client connects, but doesn't receive any event. Then the connection fails and at that moment some relevant events for the client are published. When the client reconnects, it won't send any lastEventId because it has never seen one, and as such it will never learn about these events.

We could simply work around this problem by always sending an event after a connection, which will set the client’s lastEventId. Three cases:

• client asked for history, there were history events, and whether the full requested history could be fetched or not, it now knows the latest relevant event id or it knew it already, so we're good
• client asked for history but there were no history events for them (perhaps because lastEventId was larger than it should have been, or client can't access the same channels they used to)
• client didn't ask for history

In these last two cases, simply sending an event containing the server’s lastEventId allows the client to have a reference event id in case the connection is lost. Support is optional for the client but the event will always be sent by the server.

The type of the event could be called, appropriately, lastEventId.

Stats

Some stats are computed, and are expected to be sent to Statsd or similar via a Goliath plugin. Also plugins are not ideal because they prevent using a totally different implementation of the server.
Statsd support could be included but at least an HTTP endpoint for the server could return these stats.