FAQ
I'm working with devices that are modeled as a state machine. My approach
is to use a message channel and quit channel with a goroutine for each
device. When a JSON RPC request comes in, the device is found, and the
command is routed to the channel for the device. So far so good.

Then I ran into the problem where replies fail because the
http.ResponseWriter is closed once the goroutine from the web server exits.
This was quite surprising as it doesn't seem to be documented.

I'm not a big fan of satisfying web requests in the "thread" of the web
server as it means you have locking issues as multiple threads of control
must run through your objects. The Actor model cleans up all these locking
issues. But that's hard to do when the web server is closing resources you
need to reply.

It seems the server goroutine must be blocked until the device finishes the
operation, which could be an arbitrary time later is many requests may need
to be orchestrated to generate the reply.

What's the idiomatic way of handling this? I can think of:

1. a mutex to block the server goroutine that the device goroutine will
give when done. Seems clumsy to me.
2. like (1) but with a sync channel.
3. Change the RPC to be request oriented, so a 200 status is returned
immediately and the response is sent later to the sender in a later
request.

As I'm very much a Go newbie I was wondering what the smart Go way is to
handle these kind of issues?

thanks


--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Jeremy Wall at Feb 4, 2013 at 10:01 pm

    On Mon, Feb 4, 2013 at 2:09 PM, Todd Hoff wrote:

    I'm working with devices that are modeled as a state machine. My approach
    is to use a message channel and quit channel with a goroutine for each
    device. When a JSON RPC request comes in, the device is found, and the
    command is routed to the channel for the device. So far so good.

    Then I ran into the problem where replies fail because the
    http.ResponseWriter is closed once the goroutine from the web server exits.
    This was quite surprising as it doesn't seem to be documented.

    I'm not a big fan of satisfying web requests in the "thread" of the web
    server as it means you have locking issues as multiple threads of control
    must run through your objects. The Actor model cleans up all these locking
    issues. But that's hard to do when the web server is closing resources you
    need to reply.
    It seems the server goroutine must be blocked until the device finishes
    the operation, which could be an arbitrary time later is many requests may
    need to be orchestrated to generate the reply.
    Yes but this is fine and idiomatic for go net/http consumers.

    What's the idiomatic way of handling this? I can think of:

    1. a mutex to block the server goroutine that the device goroutine will
    give when done. Seems clumsy to me.
    2. like (1) but with a sync channel.
    Either of these is fine.

    3. Change the RPC to be request oriented, so a 200 status is returned
    immediately and the response is sent later to the sender in a later request.
    Seems unnecessary.

    Another option is to not have your state machine write to the
    http.ResponseWriter directly and instead block on a response from your
    worker goroutines that your http.Handler then writes to the ResponseWriter.
    It has the advantage of keeping the IO at the edge and potentially making
    your worker functions more testable.

    As I'm very much a Go newbie I was wondering what the smart Go way is to
    handle these kind of issues?

    thanks


    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Todd Hoff at Feb 5, 2013 at 5:53 pm

    Another option is to not have your state machine write to the
    http.ResponseWriter directly and instead block on a response from your
    worker goroutines that your http.Handler then writes to the ResponseWriter.
    It has the advantage of keeping the IO at the edge and potentially making
    your worker functions more testable.
    Yep, thanks, it's a good idea and I've been considering it. Though the
    state machine part is easily independently testable. What has been
    tricky is getting all the JSON RPC/select/switch/goroutine/http etc
    logic correct, so testing that path is important. Unfortunately as
    ListenAndServe can't be closed down, this is difficult within a test
    harness.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kamil Kisiel at Feb 5, 2013 at 7:18 pm
    Are you aware of http://golang.org/pkg/net/http/httptest/#Server ?
    On Tuesday, February 5, 2013 9:52:58 AM UTC-8, Todd Hoff wrote:

    Another option is to not have your state machine write to the
    http.ResponseWriter directly and instead block on a response from your
    worker goroutines that your http.Handler then writes to the
    ResponseWriter.
    It has the advantage of keeping the IO at the edge and potentially making
    your worker functions more testable.
    Yep, thanks, it's a good idea and I've been considering it. Though the
    state machine part is easily independently testable. What has been
    tricky is getting all the JSON RPC/select/switch/goroutine/http etc
    logic correct, so testing that path is important. Unfortunately as
    ListenAndServe can't be closed down, this is difficult within a test
    harness.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Todd Hoff at Feb 6, 2013 at 10:03 pm
    Thanks Kamil, I did not see that, I'll take a look.
    On Tuesday, February 5, 2013 11:18:01 AM UTC-8, Kamil Kisiel wrote:

    Are you aware of http://golang.org/pkg/net/http/httptest/#Server ?
    On Tuesday, February 5, 2013 9:52:58 AM UTC-8, Todd Hoff wrote:

    Another option is to not have your state machine write to the
    http.ResponseWriter directly and instead block on a response from your
    worker goroutines that your http.Handler then writes to the
    ResponseWriter.
    It has the advantage of keeping the IO at the edge and potentially making
    your worker functions more testable.
    Yep, thanks, it's a good idea and I've been considering it. Though the
    state machine part is easily independently testable. What has been
    tricky is getting all the JSON RPC/select/switch/goroutine/http etc
    logic correct, so testing that path is important. Unfortunately as
    ListenAndServe can't be closed down, this is difficult within a test
    harness.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kamil Kisiel at Feb 6, 2013 at 10:33 pm
    I also submitted a CL yesterday that adds some examples to the httptest
    package which should make it a little bit more obvious how it can be used:

    https://codereview.appspot.com/7314046/

    On Wednesday, February 6, 2013 1:55:37 PM UTC-8, Todd Hoff wrote:

    Thanks Kamil, I did not see that, I'll take a look.
    On Tuesday, February 5, 2013 11:18:01 AM UTC-8, Kamil Kisiel wrote:

    Are you aware of http://golang.org/pkg/net/http/httptest/#Server ?
    On Tuesday, February 5, 2013 9:52:58 AM UTC-8, Todd Hoff wrote:

    Another option is to not have your state machine write to the
    http.ResponseWriter directly and instead block on a response from your
    worker goroutines that your http.Handler then writes to the
    ResponseWriter.
    It has the advantage of keeping the IO at the edge and potentially making
    your worker functions more testable.
    Yep, thanks, it's a good idea and I've been considering it. Though the
    state machine part is easily independently testable. What has been
    tricky is getting all the JSON RPC/select/switch/goroutine/http etc
    logic correct, so testing that path is important. Unfortunately as
    ListenAndServe can't be closed down, this is difficult within a test
    harness.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedFeb 4, '13 at 9:46p
activeFeb 6, '13 at 10:33p
posts6
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase