Working with streams

[Ivan]

I have created a fairly basic structure to accept streaming connections.  Using meetup as an example:

import dispatch._
val uri = "http://stream.meetup.com/2/rsvps"
val f = { msg: String => println("MSG: " + msg) }
val http = new nio.Http
http(url(uri) ^-- {msg => f(msg)})

Code works except under erroneous conditions, so the next step is to add an exception listener:

val exceptionListener = { case t: Throwable => println("exception: "+t)}
http(url(uri) ^-- {msg => f(msg)} ^! exceptionListener)

This code works well for unknown hosts, but no exception is raised for invalid urls or if the connection is lost.  Is there a way to check for error conditions with callbacks?

Cheers,

Ivan

[n8han]

On 06/19/2011 10:54 PM, Ivan [via Databinder] wrote:
> val exceptionListener = { case t: Throwable => println("exception: "+t)}
> http(url(uri) ^-- {msg => f(msg)} ^! exceptionListener)
>
> This code works well for unknown hosts, but no exception is raised for
> invalid urls or if the connection is lost.  Is there a way to check
> for error conditions with callbacks?

Invalid url not calling the listener is a bug then, then. Something must
be swallowing an exception.

https://github.com/n8han/Databinder-Dispatch/issues/30

For connection loss, that is a feature gap. When the connection shuts
down cleanly (as the meetup streams will do, given the chance) there
would be no exception. I guess we also need a connection close listener?
Can you think of any other gaps, since you are using this? Twine is the
extent of my use of it, but ^--  was too cool not to share.

Nathan

[Ivan]

n8han wrote

Invalid url not calling the listener is a bug then, then. Something must
be swallowing an exception.

https://github.com/n8han/Databinder-Dispatch/issues/30

At this point, invalid urls is not much of a concern since they are validated beforehand in my app.  Only noticed the issue when testing out the exception listener.

n8han wrote

For connection loss, that is a feature gap. When the connection shuts
down cleanly (as the meetup streams will do, given the chance) there
would be no exception. I guess we also need a connection close listener?
Can you think of any other gaps, since you are using this? Twine is the
extent of my use of it, but ^--  was too cool not to share.

Nathan

Loss of connection is a different type of exception, so a different listener would be better, especially if you would not want to catch specific exceptions in the existing listener.  I am not only working with meetup streams, so I need to account for any type of connection loss: client or server side, clean or abrupt.  A connection close listener would allow me to apply retry logic, while the existing listener would capture exceptions and close the stream/thread.

Ivan

[n8han]

On 06/20/2011 09:25 AM, Ivan [via Databinder] wrote:

Loss of connection is a different type of exception, so a different listener would be better, especially if you would not want to catch specific exceptions in the existing listener.  I am not only working with meetup streams, so I need to account for any type of connection loss: client or server side, clean or abrupt.  A connection close listener would allow me to apply retry logic, while the existing listener would capture exceptions and close the stream/thread.

Okay, opened a bug for this too.

https://github.com/n8han/Databinder-Dispatch/issues/32

Nathan