I have a better understanding of the problem after reviewing the doc and we need to decide on what lifecycle scope we want the `Connection`, `Session`, and `MessageConsumer` to have.
It looks like for the `Connection` we should try to have at most one instance for the entire process per connection factory. https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html says that the connection should be re-used. Having less connections would likely be beneficial unless you think there would be a performance limitation of using a single connection per process for all the messages? For the `Session` and `MessageConsumer`, I'm not sure what lifecycle scope it should have. Some ideas: 1. we could make it so that each `Session` is unique per checkpoint, e.g. we hand off the ownership of the `Session` to the JmsCheckpointMark everytime we checkpoint and create a new `Session` for the next set of messages we receive. This would mean that we would also close the `MessageConsumer` at every checkpoint and create a new one. 2. we could make it so that the `Session` is scoped to the reader start/close and possibly multiple checkpoint marks and effectively close the `Session` once the reader is closed and all checkpoint marks are finalized/expired. We would close the `MessageConsumer` whenever the reader is closed. 3. we could make it so that the `Session` is scoped to the `Connection` and would only close it when the `Connection` closes. 1 seems pretty simple since the ownership of the `Session` is always owned by a single distinct owner. This seems like it would make the most sense if `Session` creation and management was cheap. Another positive is that once the `Session` closes any messages that weren't acknowledged are returned back to the queue and we will not have to wait for the reader to be closed or all the checkpoint marks to be finalized. What do you think? On Mon, Aug 29, 2022 at 10:06 PM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi Vincent, > > thanks, I will take a look (as original JmsIO author ;)). > > Regards > JB > > On Mon, Aug 29, 2022 at 6:43 PM BALLADA Vincent > <vincent.ball...@renault.com> wrote: > > > > Hi all, > > > > > > > > Here is a PR related to the following issue (Runner acknowledges > messages on closed session): > > > > https://github.com/apache/beam/issues/20814 > > > > > > > > And here is a documentation explaining the fix: > > > > > https://docs.google.com/document/d/19HiNPoJeIlzCFyWGdlw7WEFutceL2AmN_5Z0Vmi1s-I/edit?usp=sharing > > > > > > > > And finally the PR: > > > > https://github.com/apache/beam/pull/22932 > > > > > > > > Regards > > > > > > > > Vincent BALLADA > > > > > > > > > > > > > > Confidential C > > > > -- Disclaimer ------------------------------------ > > Ce message ainsi que les eventuelles pieces jointes constituent une > correspondance privee et confidentielle a l'attention exclusive du > destinataire designe ci-dessus. Si vous n'etes pas le destinataire du > present message ou une personne susceptible de pouvoir le lui delivrer, il > vous est signifie que toute divulgation, distribution ou copie de cette > transmission est strictement interdite. Si vous avez recu ce message par > erreur, nous vous remercions d'en informer l'expediteur par telephone ou de > lui retourner le present message, puis d'effacer immediatement ce message > de votre systeme. > > > > *** This e-mail and any attachments is a confidential correspondence > intended only for use of the individual or entity named above. If you are > not the intended recipient or the agent responsible for delivering the > message to the intended recipient, you are hereby notified that any > disclosure, distribution or copying of this communication is strictly > prohibited. If you have received this communication in error, please notify > the sender by phone or by replying this message, and then delete this > message from your system. >
