A goal of this websocket work is to enable a large number of clients to
access the log information. Websockets has better support across browsers
(SSE is missing in IE).

Other than Hysterix (which doesn't seem to be a logging consumer really),
do you know of any other clients that primarily accept SSE?


On Wed, Jan 22, 2014 at 11:40 AM, Patrick Mueller wrote:

Has any thought been given to also making log data available via
server-sent events [1]?

I've only used these once, with Netflix's Hystrix dashboard, and found it
SUPER EASY to generate an event stream to feed the Hystrix dashboard. I
assume it's just as easy for code to consume it.

I'm not sure what all loggregator can do - server-sent events are an
output-only thing - you only interact with it by reading the stream, no
writing once it's started. Of course, you could use URL patterns, query
parameters on the URL, etc to select streams, filter, etc.


On Wed, Jan 22, 2014 at 11:37 AM, Mike Heath wrote:

Hey Johannes,

Thanks for taking a look at this.

You could modify the server without modifying the client. The server
could periodically send ping frames. If the server does not receive any
frames (a pong frame or otherwise) after a certain threshold, it assume the
connection is stale and closes it. This will work with the existing the
clients that send an "I'm still here!" text frame and will work with newer
clients that use ping/pong. Clients going forward can then close their
connection (or try to ping the server) if they don't receive any frames
after a certain amount of time.

Just a suggestion. Thanks again for the response.


On Wed, Jan 22, 2014 at 9:13 AM, Johannes Tuchscherer <> wrote:
Hi Mike,

Thanks for digging through the code and coming up with improvements. We
really appreciate that.

That WebSocket implementation looks interesting and powerful. Indeed, we
could rip out some code from the loggregator and the CLI by switching over
to that implementation. BTW, it looks like this library got merged into the
Gorilla project and is now available here:

Switching to that implementation, though, comes at the cost of
increasing the number of our third party dependencies. Considering we
already wrote our keep-alive logic, we don't get an immediate benefit from
switching right now. The other difficulty comes from the coupling between
loggregator an CLI. If we use a new WebSocket implementation on the server,
we have to update the CLI at the same time and we would need to handle
both, the ping-pong frames and the old implementation for backwards
compatibility with existing clients.

Nevertheless, we see the benefit for the community in switching over to
a more standard conform implementation. I will put in a story in our
Pivotal Tracker Icebox and talk to our Product Owner about it.

Thanks again for coming up with all these suggestions,
On Tuesday, January 21, 2014 6:04:16 PM UTC-7, Mike Heath wrote:

Has the loggregator team considered using Gary's Burd's WebSocket
implementation (
websocket) instead of Go's built-in WebSocket library? Go's built-in
library doesn't appear to support ping/pong frames (which seems weird that
a Google invented protocol would have a half-baked implementation in a
Google runtime...)

It seems kind of silly to do stuff like this
cloudfoundry/cli/blob/master/src/cf/api/logs.go#L125-L130 rather than
using the WebSocket protocol's built-in mechanism for detecting stale

Forgive me if I sound like a whiner. I love Loggregator. I just keep
finding things in Loggregator that are done in a way that's easy with Go
but non-standard which causes more effort for those of us on more
established platforms.

On Friday, January 17, 2014 6:21:24 PM UTC-7, Mike Heath wrote:

I'm really close to having a fully functional Loggregator client in
Java for both emitting logs as well as reading logs over Web Sockets.

There a few things that are bugging me so I thought I'd provide some

- I'm not very fond of the DIY padding. PKCS#7 is really really easy
to implement (since Go doesn't appear to support it.) Why not go with this
standard padding mechanism? Regardless, it works but it was a pain to
figure out and reimplement.
- The signature in the LogEnvelope only covers the LogMessage's
message field and not the entire LogMessage. This probably isn't a huge
problem since it would still be rather difficult to intercept a LogEnvelope
but if you did, you could emit the same message to any application
masquerading as coming from any source. It seems more secure, to apply the
digital signature to the entire LogMessage but again, not a big deal.
- The nonsecond time resolution in the timestamp seems a little over
the top but I don't anticipate being around on April 11, 2262 when it
overflows so I'm not too concerned. :)

I'll post a link to my client once it's ready.


To unsubscribe from this group and stop receiving emails from it, send
an email to

Patrick Mueller

To unsubscribe from this group and stop receiving emails from it, send an
email to
To unsubscribe from this group and stop receiving emails from it, send an email to

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 7 of 10 | next ›
Discussion Overview
groupvcap-dev @
postedJan 18, '14 at 1:21a
activeJan 24, '14 at 5:53a



site design / logo © 2021 Grokbase