Announcement Announcement Module
Collapse
No announcement yet.
Too much runnable on pollable channel Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Too much runnable on pollable channel

    if i create poller with unlimited or big thread stack and short interval, then all threads for a short period of time will be executed and sleep on Poll method of AbstractPollingEndpoint which will sleep on inputChannel.receive().
    So many instances pool's threads will be running and busyed at once without necessity. So i can't use single pool thread executor on many channels because if i uncorrect point these parametrs some poller could occupy all threads of pool, and another channels should be wait.
    why there is not pollable consumer with scheme like this:
    Code:
      
    public void poll() {
            for (;;) {
              pool.execute(new Handler(inputChannel.receive()));
            }

  • #2
    I'm not sure what you are trying to say, but your code doesn't compile. What's a Handler?

    Do you mean that you would like all the receive() invocations in a single poll() to happen sequentially in the same thread? I don't see why blocking on receive() will be worse than blocking on send(). I can imagine though that it is possible to deadlock the system if you don't use maxMessagesPerPoll. It could be that you've found a hole that makes this unreasonably easy to do (i.e. unreasonably hard to prevent).

    If you could come up with a testcase that shows the breakage you're trying to describe I'd be very keen to have a look at that.

    Comment

    Working...
    X