Best design to solve this problem

I have a test harness that does roughly the same than yours and I guess the main problem is that you want to fire the SOAP calls in parallel.

Of course you can't simply start 2000 actors and fire the calls - the server is likely to refuse or stall.

My program uses a simple fixed thread-pool. The calls are submitted in a for over a projection that yields the (lazy) list of Futures. Finally this list goes into a foreach to compute some statistics and log the individual call results.

That's very simple and works extremely well. I tried to rewrite it to use Actors, but the result wasn't pleasing at all

• Controlling the degree of parallelism is non-trivial. I ended up with a bunch of actors that implement the queueing/dispatch
• The code got less readable as you loose type safety
• It was 10-15 times slower that the original solution
  

/Carsten


On Thu, Dec 25, 2008 at 11:17 PM, Tim Perrett <hello@timperrett.com> wrote:

Hey guys!

I've been noodling how to solve something, and just thought id ask a few
questions as I think Actors are the way to go, but having some clarification
would be great...

In short, I have to parse an XML file, and then make a bunch of SOAP calls
based on the contents of said XML file. My thinking was to use Actors to
create a queue which then dispatches the SOAP calls...?

This application will be run via cron job, so the fact that its blocking is
not much of an issue, however id like to design it in an elegant and
efficient way.

Any thoughts / suggestions would be awesome.

Happy holidays everyone :)

Tim

Hey Carsten,

Thanks for your reply - I think perhaps I was not clear enough in my first
email. I don't want to send the SOAP calls in parallel, that would indeed be
madness and very non-trivial :-)

I was wondering if I could create a queue with an Actor, on which the SOAP
calls to be sent are clicked through one one by one in a FIFO manner. It
struck me that as the RPC calls will take an inordinate amount longer to
complete than the configuration load so having a system where the config
loader is just passing a message to a dispatching Actor would be a neater
solution?

If I wasn't to use Actors, my worry would be that if one of the soap calls
bombed out totally (quite possible, depending on environmental factors),
this might kill off the entire application thread, rather that letting me do
call retrying in the event of failures etc.

Interested in your thoughts / feedback :-)

Cheers

Tim

On 26/12/2008 11:06, "Carsten Saager" wrote:

> I have a test harness that does roughly the same than yours and I guess the
> main problem is that you want to fire the SOAP calls in parallel.
>
> Of course you can't simply start 2000 actors and fire the calls - the server
> is likely to refuse or stall.
>
> My program uses a simple fixed thread-pool. The calls are submitted in a for
> over a projection that yields the (lazy) list of Futures. Finally this list
> goes into a foreach to compute some statistics and log the individual call
> results.
>
> That's very simple and works extremely well. I tried to rewrite it to use
> Actors, but the result wasn't pleasing at all
> * Controlling the degree of parallelism is non-trivial. I ended up with a
> bunch of actors that implement the queueing/dispatch
> * The code got less readable as you loose type safety
> * It was 10-15 times slower that the original solution
> /Carsten
>
>
> On Thu, Dec 25, 2008 at 11:17 PM, Tim Perrett wrote:
>> Hey guys!
>>
>> I've been noodling how to solve something, and just thought id ask a few
>> questions as I think Actors are the way to go, but having some clarification
>> would be great...
>>
>> In short, I have to parse an XML file, and then make a bunch of SOAP calls
>> based on the contents of said XML file. My thinking was to use Actors to
>> create a queue which then dispatches the SOAP calls...?
>>
>> This application will be run via cron job, so the fact that its blocking is
>> not much of an issue, however id like to design it in an elegant and
>> efficient way.
>>
>> Any thoughts / suggestions would be awesome.
>>
>> Happy holidays everyone :)
>>
>> Tim
>>
>>
>
>

given that you don't want them in parrellel I wouldn't bother with
actors, they don't bring any handling for tcp etc for free you still
have to add that.

Given that I would just do it inline in the main thread and keep
things very simple.

On Fri, Dec 26, 2008 at 8:07 PM, Tim Perrett wrote:
>
> Hey Carsten,
>
> Thanks for your reply - I think perhaps I was not clear enough in my first
> email. I don't want to send the SOAP calls in parallel, that would indeed be
> madness and very non-trivial :-)
>
> I was wondering if I could create a queue with an Actor, on which the SOAP
> calls to be sent are clicked through one one by one in a FIFO manner. It
> struck me that as the RPC calls will take an inordinate amount longer to
> complete than the configuration load so having a system where the config
> loader is just passing a message to a dispatching Actor would be a neater
> solution?
>
> If I wasn't to use Actors, my worry would be that if one of the soap calls
> bombed out totally (quite possible, depending on environmental factors),
> this might kill off the entire application thread, rather that letting me do
> call retrying in the event of failures etc.
>
> Interested in your thoughts / feedback :-)
>
> Cheers
>
> Tim
>
>
> On 26/12/2008 11:06, "Carsten Saager" wrote:
>
>> I have a test harness that does roughly the same than yours and I guess the
>> main problem is that you want to fire the SOAP calls in parallel.
>>
>> Of course you can't simply start 2000 actors and fire the calls - the server
>> is likely to refuse or stall.
>>
>> My program uses a simple fixed thread-pool. The calls are submitted in a for
>> over a projection that yields the (lazy) list of Futures. Finally this list
>> goes into a foreach to compute some statistics and log the individual call
>> results.
>>
>> That's very simple and works extremely well. I tried to rewrite it to use
>> Actors, but the result wasn't pleasing at all
>> * Controlling the degree of parallelism is non-trivial. I ended up with a
>> bunch of actors that implement the queueing/dispatch
>> * The code got less readable as you loose type safety
>> * It was 10-15 times slower that the original solution
>> /Carsten
>>
>>
>> On Thu, Dec 25, 2008 at 11:17 PM, Tim Perrett wrote:
>>> Hey guys!
>>>
>>> I've been noodling how to solve something, and just thought id ask a few
>>> questions as I think Actors are the way to go, but having some clarification
>>> would be great...
>>>
>>> In short, I have to parse an XML file, and then make a bunch of SOAP calls
>>> based on the contents of said XML file. My thinking was to use Actors to
>>> create a queue which then dispatches the SOAP calls...?
>>>
>>> This application will be run via cron job, so the fact that its blocking is
>>> not much of an issue, however id like to design it in an elegant and
>>> efficient way.
>>>
>>> Any thoughts / suggestions would be awesome.
>>>
>>> Happy holidays everyone :)
>>>
>>> Tim
>>>
>>>
>>
>>
>
>
>

Tim,

Actors seem an overkill to me for this problem.

If a dying thread is your main concern, use an Executors.newSingleThreadExecutor(), this will relaunch a new worker thread in case the original one dies.

val ec = Executors.newSingleThreadExecutor

mytasks.foreach{callable =>
  var failCount=4
  while(failCount>0) {
   try {
    ec.submit(callable).get
    failCount=0
   } catch {
     case _ => failCount = failCount-1
   }
  if (failCount>0) throw new Error("given up")
}

/Carsten

On Fri, Dec 26, 2008 at 8:07 PM, Tim Perrett <hello@timperrett.com> wrote:

Hey Carsten,

Thanks for your reply - I think perhaps I was not clear enough in my first
email. I don't want to send the SOAP calls in parallel, that would indeed be
madness and very non-trivial :-)

I was wondering if I could create a queue with an Actor, on which the SOAP
calls to be sent are clicked through one one by one in a FIFO manner. It
struck me that as the RPC calls will take an inordinate amount longer to
complete than the configuration load so having a system where the config
loader is just passing a message to a dispatching Actor would be a neater
solution?

If I wasn't to use Actors, my worry would be that if one of the soap calls
bombed out totally (quite possible, depending on environmental factors),
this might kill off the entire application thread, rather that letting me do
call retrying in the event of failures etc.

Interested in your thoughts / feedback :-)

Cheers

Tim


On 26/12/2008 11:06, "Carsten Saager" <csaager@gmail.com> wrote:

> I have a test harness that does roughly the same than yours and I guess the
> main problem is that you want to fire the SOAP calls in parallel.
>
> Of course you can't simply start 2000 actors and fire the calls - the server
> is likely to refuse or stall.
>
> My program uses a simple fixed thread-pool. The calls are submitted in a for
> over a projection that yields the (lazy) list of Futures. Finally this list
> goes into a foreach to compute some statistics and log the individual call
> results.
>
> That's very simple and works extremely well. I tried to rewrite it to use
> Actors, but the result wasn't pleasing at all
> * Controlling the degree of parallelism is non-trivial. I ended up with a
> bunch of actors that implement the queueing/dispatch
> * The code got less readable as you loose type safety
> * It was 10-15 times slower that the original solution
> /Carsten
>
>
> On Thu, Dec 25, 2008 at 11:17 PM, Tim Perrett <hello@timperrett.com> wrote:
>> Hey guys!
>>
>> I've been noodling how to solve something, and just thought id ask a few
>> questions as I think Actors are the way to go, but having some clarification
>> would be great...
>>
>> In short, I have to parse an XML file, and then make a bunch of SOAP calls
>> based on the contents of said XML file. My thinking was to use Actors to
>> create a queue which then dispatches the SOAP calls...?
>>
>> This application will be run via cron job, so the fact that its blocking is
>> not much of an issue, however id like to design it in an elegant and
>> efficient way.
>>
>> Any thoughts / suggestions would be awesome.
>>
>> Happy holidays everyone :)
>>
>> Tim
>>
>>
>
>

Thanks Chris - I understand that Actors don't bring anything in terms of
tcp; I can handle that myself.

So by the sounds of it, id be best to just process my configurations into a
List() or something, and then just iterate over the list to execute the
calls - and this should all be cool to do in the main thread, as a blocking
operation?

Cheers

Tim

On 26/12/2008 19:26, "Chris Twiner" wrote:

> given that you don't want them in parrellel I wouldn't bother with
> actors, they don't bring any handling for tcp etc for free you still
> have to add that.
>
> Given that I would just do it inline in the main thread and keep
> things very simple.
>
> On Fri, Dec 26, 2008 at 8:07 PM, Tim Perrett wrote:
>>
>> Hey Carsten,
>>
>> Thanks for your reply - I think perhaps I was not clear enough in my first
>> email. I don't want to send the SOAP calls in parallel, that would indeed be
>> madness and very non-trivial :-)
>>
>> I was wondering if I could create a queue with an Actor, on which the SOAP
>> calls to be sent are clicked through one one by one in a FIFO manner. It
>> struck me that as the RPC calls will take an inordinate amount longer to
>> complete than the configuration load so having a system where the config
>> loader is just passing a message to a dispatching Actor would be a neater
>> solution?
>>
>> If I wasn't to use Actors, my worry would be that if one of the soap calls
>> bombed out totally (quite possible, depending on environmental factors),
>> this might kill off the entire application thread, rather that letting me do
>> call retrying in the event of failures etc.
>>
>> Interested in your thoughts / feedback :-)
>>
>> Cheers
>>
>> Tim
>>
>>
>> On 26/12/2008 11:06, "Carsten Saager" wrote:
>>
>>> I have a test harness that does roughly the same than yours and I guess the
>>> main problem is that you want to fire the SOAP calls in parallel.
>>>
>>> Of course you can't simply start 2000 actors and fire the calls - the server
>>> is likely to refuse or stall.
>>>
>>> My program uses a simple fixed thread-pool. The calls are submitted in a for
>>> over a projection that yields the (lazy) list of Futures. Finally this list
>>> goes into a foreach to compute some statistics and log the individual call
>>> results.
>>>
>>> That's very simple and works extremely well. I tried to rewrite it to use
>>> Actors, but the result wasn't pleasing at all
>>> * Controlling the degree of parallelism is non-trivial. I ended up with a
>>> bunch of actors that implement the queueing/dispatch
>>> * The code got less readable as you loose type safety
>>> * It was 10-15 times slower that the original solution
>>> /Carsten
>>>
>>>
>>> On Thu, Dec 25, 2008 at 11:17 PM, Tim Perrett wrote:
>>>> Hey guys!
>>>>
>>>> I've been noodling how to solve something, and just thought id ask a few
>>>> questions as I think Actors are the way to go, but having some
>>>> clarification
>>>> would be great...
>>>>
>>>> In short, I have to parse an XML file, and then make a bunch of SOAP calls
>>>> based on the contents of said XML file. My thinking was to use Actors to
>>>> create a queue which then dispatches the SOAP calls...?
>>>>
>>>> This application will be run via cron job, so the fact that its blocking is
>>>> not much of an issue, however id like to design it in an elegant and
>>>> efficient way.
>>>>
>>>> Any thoughts / suggestions would be awesome.
>>>>
>>>> Happy holidays everyone :)
>>>>
>>>> Tim
>>>>
>>>>
>>>
>>>
>>
>>
>>
>

On 12/27/08, Chris Twiner wrote:
> given that you don't want them in parrellel I wouldn't bother with actors, they don't bring any handling for tcp etc for free you still have to add that.

Coming from Erlang's concurrency model, I was most thrilled to find
Scala's Actors had the same semantics with a far cleaner syntax and
more expressive type system. But one of the things I absolutely adored
about Erlang was the interaction between Erlang processes and sockets,
which acted like another Erlang process, sending messages to the
owning process on various TCP events.

I wonder how trivial (or non-trivial) implementing some sort of socket
Actor would be...

On Fri, Dec 26, 2008 at 10:50 PM, Tim Perrett wrote:
>
> Thanks Chris - I understand that Actors don't bring anything in terms of
> tcp; I can handle that myself.
>
> So by the sounds of it, id be best to just process my configurations into a
> List() or something, and then just iterate over the list to execute the
> calls - and this should all be cool to do in the main thread, as a blocking
> operation?
>

Sounds best to me, anything else (when you don't require parrellel
sending) is just overkill imo.