gemmellr commented on pull request #44:
URL: https://github.com/apache/qpid-jms/pull/44#issuecomment-1055436409
Having just read them all, the existing feedback and questions (e.g impact
on default case) on the code and in the discussion essentially all still seems
to apply now (even some
gemmellr commented on pull request #44:
URL: https://github.com/apache/qpid-jms/pull/44#issuecomment-957323951
I think single completion at a time is the way to go, at least by default,
it just shouldn't really be a concern when using it whether the callback
execution is fair or not.
--
gemmellr commented on pull request #44:
URL: https://github.com/apache/qpid-jms/pull/44#issuecomment-957323951
I think single completion at a time is the way to go, at least by default,
it just shouldn't really be a concern when using it whether the callback
execution is fair or not.
--
gemmellr commented on pull request #44:
URL: https://github.com/apache/qpid-jms/pull/44#issuecomment-957323951
I think single completion at a time is the way to go, at least by default,
it just shouldn't really be a concern when using it whether the callback
execution is fair or not.
--
gemmellr commented on pull request #44:
URL: https://github.com/apache/qpid-jms/pull/44#issuecomment-954685729
The current/second version isnt quite what I had in mind when it occurred to
me the connection executor was already there. You made it a sort of hybrid
still mostly like your
gemmellr commented on pull request #44:
URL: https://github.com/apache/qpid-jms/pull/44#issuecomment-954013660
I didnt say it would be per connection. You asked about lifecycle. Factories
dont have any 'close'. Connections do. Hence..
--
This is an automated message from the Apache Git
gemmellr commented on pull request #44:
URL: https://github.com/apache/qpid-jms/pull/44#issuecomment-954001487
There will definitely be no finalizers :) I think the connection is the most
likely choice for a shared thing enabled by config.
--
This is an automated message from the Apache
gemmellr commented on pull request #44:
URL: https://github.com/apache/qpid-jms/pull/44#issuecomment-953985144
Ok. It seemed like you wanted to make it the default.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
gemmellr commented on pull request #44:
URL: https://github.com/apache/qpid-jms/pull/44#issuecomment-953964068
I'm not sure I like the idea of taking similar approach as 45, which I hadnt
seen to look at yet (can only keep up with so many different large and invasive
changes while trying
gemmellr commented on pull request #44:
URL: https://github.com/apache/qpid-jms/pull/44#issuecomment-953768863
Alternatively, the connection already has an executor of its own (used for
the exception listener etc to avoid blocking the event loop), an option could
just be to use that for
gemmellr commented on pull request #44:
URL: https://github.com/apache/qpid-jms/pull/44#issuecomment-953711606
Using the event loop is out of the question, it runs the inner core and the
callback is allowed to do most stuff on the outer connection that it services.
Disaster waiting to
gemmellr commented on pull request #44:
URL: https://github.com/apache/qpid-jms/pull/44#issuecomment-953656355
Sure. However there is a fairly decent window that will happen even with 1
session with how it is done just now. Consider where it will often execute a
second task for the same
gemmellr commented on pull request #44:
URL: https://github.com/apache/qpid-jms/pull/44#issuecomment-953635551
I dont believe it will ever work the way you want with a simple queue of any
size. You have to add hoops to manipulate it into behaving that way. E.g by
pretending the queue is
gemmellr commented on pull request #44:
URL: https://github.com/apache/qpid-jms/pull/44#issuecomment-953007869
So, one 'slight' problem with this hehe. It doesnt do at all what is
described or I think both of us initially thought it would be doing. Digging
into the executor behaviour,
14 matches
Mail list logo
