Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Ignoring the returned promise means the request is never executed #50

Closed
pr1001 opened this Issue Apr 3, 2013 · 6 comments

Comments

3 participants

pr1001 commented Apr 3, 2013

Based on a mailing list discussion

The Scala promise coming in Dispatch 0.10 will apparently fix this. For now, this is a workaround for Dispatch 0.9.5:

http(request > handler).map(identity)

This forces dispatch to register the listener associated with the request handler.

This is still an issue in 0.10 on scala 2.10

Contributor

n8han commented Apr 16, 2013

Could you provide some code to demonstrate what you're seeing?

Not sure if I am missing something obvious, but here is a simple test case.

https://gist.github.com/rickeyvisinski-kanban/5399383

Contributor

n8han commented Apr 22, 2013

This works as expected in 0.10, just tested it.

@rickeyvisinski-kanban I stepped through some of your code in the console. The first problem I ran into is that the response for that URL is a 302 redirect, and OK will only accept a 20x response. A StatusCode exception would be produced if you applied the promise (which seems like a better option than Thread.sleep for preventing early termination of the program).

After I added a www subdomain the request succeeded, but the jsoup extraction didn't seem to find anything. I would encourage using the console to test out this kind of service interaction before coding it into a larger program, where errors are harder to pin down.

@n8han n8han closed this Apr 22, 2013

Hey,

Thanks for taking the time to look at this. Apparently I didn't vet the test case I threw together enough. The actual application fetches tarballs from an internal server and writes them out for processing, which unfortunately isn't testable for anyone else.

The app also used buffered writer instead of file writer which cause the program to terminate before the buffer was flushed, hence the thread sleep.

I will try to make a better test case this weekend because it still seems like I am missing something having to apply the promise in order to process the list.

Let me know if you think the mailing list would be a better place for this.

Contributor

n8han commented Apr 26, 2013

Yep, you'll find a wider audience on the mailing list.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment