Updated revisions of libs: scodec 1.10, scalaz-stream 0.8.1, scalaz 7… #111
Conversation
|
I think it is fine to merge this as whole. WDYT @timperrett ? |
| private[remotely] def fullyRead(s: Process[Task,BitVector]): Task[BitVector] = s.runFoldMap(x => x) | ||
|
|
||
| private[remotely] def fixedNamedThreadPool(name: String): ExecutorService = | ||
| Executors.newFixedThreadPool(Runtime.getRuntime.availableProcessors, namedThreadFactory(name)) | ||
| Executors.newFixedThreadPool(Runtime.getRuntime.availableProcessors.max(4), namedThreadFactory(name)) |
There was a problem hiding this comment.
Is this what one would always want?
There was a problem hiding this comment.
They may not, it's true, and this isn't currently configurable. I'm going to remove this when I re-base as I don't believe it affects us (it was the worker threads going below 3 threads were we saw lags even when only sending one in at a time). This is only currently used by endpoint when you have multiple endpoints set.
|
@sbuzzard @ahjohannessen I think this looks like a great change set. If we can rebase to the latest master then we can get it merged in. |
sbuzzard
force-pushed
the
bump-rev-min-threads-in-pool
branch
from
a3cb9cd
to
139e7b3
Compare
|
Probably smart to bump travis & build to use scala 2.11.8 as scodec, shapeless etc. are using 2.11.8 and macroparadise with 2.11.8 |
…e boost flushing pipeline, minimizing default worker threads and fix of concurrency bug in negotiation.
sbuzzard
force-pushed
the
bump-rev-min-threads-in-pool
branch
from
139e7b3
to
885f805
Compare
….1.8, commons-pool-2.4.2, netty 4.1.0, flush client request in pipeline to avoid ~1 sec lags, minimum of 4 default endpoint and worker threads to avoid 100 to 200ms lags with single CPU machines awaiting for free connection.
This subsumes PRs 106 - 108 and adds:
1.) update of scodec, scalaz-stream (0.8.x) and scalaz (7.1.x) to latest.
2.) sets a minimum for endpoint and worker threads when they are not set by client but default to num processors, as it has been observed that there were lags even when processing one request at a time when the thread pool were less than 4 due to non-connection use of the thread (overhead, decoding, encoding). The worker threads can be configured to be higher, obviously, but endpoint pool can't. If acceptable and it is desired to merge 106 - 108 individually, I can re-base this to just include the deltas. Or if it is desired just to bump the versions and not include the thread pool changes. @ahjohannessen, FYI ...
These changes constitutes the deltas from 1.4.3 which we are using in our application now.