> > @Bill, why do you think your's is 'better' than handing the long
> running task to another thread, especially one from a different thread
> pool?
> >
>
> I don't have a problem with saying this is 'better' or not. I do have
> a problem with saying that this is wrong, because its not. Defining
> and configuring multiple thread pools can be a burden on both the admin
> and developer, not to mention the extra code the developer has to
> write.
But Bill, only if the programmer puts the burden into a second thread pool,
the administrator can adjust the behaviour of the container by tuning the
pools differently. If instead the programmer follows your pattern, the
administrator has no chance for tuning, as the container does not "see" the
different work types of protocol level processing (hence blocking LAN ports)
and application level processing (hence blocking CPU cores). So I have to
say that it is always correct to do it in Marek's way as it opens this
possibilities of performance tuning, resource cab and division of labour,
while it could become (at least) problematic to do it in your way (unless in
a DevOps scenario).
So I understand what Marek means with "wrong", while I would rather call it
"suboptimal for production use": It might only show up its problems in heavy
load scenarios, when the lots of CPU cores have long pause times due to the
few overloaded LAN ports of the host and the admin cannot see where the
problems comes from. He only sees "sleeping application load" and "fully
exhausted protocol load" - but will typically interpret this monitor display
as "blocking I/O in the application layer -- I should call the vendor to fix
this!" and "lots of http traffic on one port -- I should add more LAN
adapters!".
Regards
Markus