[Haskell-cafe] External system connections

[Richard Wallace]

On Sun, Jul 10, 2011 at 2:54 PM, Brandon Allbery <allbery.b at gmail.com> wrote:
> On Sun, Jul 10, 2011 at 17:34, Richard Wallace
> <rwallace at thewallacepack.net> wrote:
>> Rather than a single separate thread that makes requests I was hoping to
>> make several soap requests concurrently, rather than have them be made
>> serially.  I would only want to block other threads making soap request if
>> one of them returns a response indicating the token they were using is no
>> longer valid.
>
> Is there one shared token, or one per requesting thread, or some other
> arrangement?

There should be one shared token.

> In either case, separation of concerns makes me think
> the token handling belongs on the other end:  a thread writes a
> request down a Chan, a queue dispatcher thread reads it if there are
> available workers and the token is available (with callers blocking
> otherwise), dispatcher sends request to available worker.  If the
> worker finds the token is invalid, it calls back in to the dispatcher
> with a token renewal request, which causes anything else that needs
> that token to block as above, and itself blocks until a valid token is
> returned.

Ahhh... I see.  That sounds like a much better plan.  It also keeps
the fact that the token is "mutable" confined to a single thread, the
dispatcher thread.

One thing I'd have to be careful to handle is iIf multiple worker
threads find that the token is now invalid.  In that case they would
all send the token renewal request to the dispatcher and they would
each try and do the re-auth.  To avoid that, part of the token renewal
request could be the used token.  When the dispatcher does the token
renewal, it checks if the used token is the same as the current token.
 If so, it does the token renewal.  If not, it dispatches to the SOAP
worker thread with the new token.

> Another advantage of this is that adding more workers is
> done in an obvious place (the queuer thread).
>
> That said, I still don't know enough details to say if that token
> management implementation actually makes sense.  I'd still go with the
> worker/queuer thread setup, which is I think what you were pointed to
> (the pool hackage).
>

Ok, I still don't see how the Pool package helps.  I had assumed the
pooled resource would be the token, so the size of the pool would be
1.   Now that I rethink it, it seems like you are suggesting the
resource is the worker threads.  Is that right?  When I read what you
were talking about above with the dispatcher thread I had thought it
would use forkIO to start the worker threads.  The worker threads
would read from a Chan that the dispatcher wrote to.    In that way,
the dispatcher doesn't have to worry about worker threads being
available.  Am I misunderstanding something?

Thanks,
Rich

> --
> brandon s allbery                                      allbery.b at gmail.com
> wandering unix systems administrator (available)     (412) 475-9364 vm/sms
>