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 |
Administrator
|
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 |
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. 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 |
Administrator
|
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 |
Free forum by Nabble | Edit this page |