[AMQ-8324] Add design doc for Jakarta Messaging 3.1 asynchronous send #1390
Conversation
|
I don't really like the use of images as they are not easily modifiable. Markdown supports code blocks (and you can mark it as java) so I would use something like that instead. |
| @@ -0,0 +1,225 @@ | |||
| # Jakarta Messaging 3.1: asynchronous send design doc | |||
|
|
|||
| Date: Jan 5th 2025 | |||
There was a problem hiding this comment.
I would not add date here (the PR date is good enough 😄 ).
+1 for this |
|
Use codeblock instead of image. |
|
I haven't had a chance to get back to looking at this yet but still plan to, @mattrpav have you had a change to review this yet? |
|
|
||
| **Approach 2: Application thread submits the async send to a work queue, a single background thread will dequeue a message from the queue, send it asynchronously and wait for it to finish, before dequeuing the next.** | ||
|
|
||
| This is similar to approach 1, the async message is sent one at a time. The difference being instead of doing it in the application thread, the `Session` object will have a `SingleThreadExecutor` to handle sending of the messages on a background thread. The advantage of doing that is the application thread is not blocked by sending an async message, it simply enqueues the message to the work queue (ExecutorService) then proceeds. Allowing it to batch send a lot of async messages at a time without blocking. |
There was a problem hiding this comment.
each send on the executor would still need a round trip to the server on this case.
you are only unblocking the sender's thread., right?
There was a problem hiding this comment.
wouldn't be possible to have a completion callback on the storage, sending responses to the client upon callback?
Add design doc for implementing Jakarta Messaging 3.1 asynchronous send per the latest process discussed on dev list.
Note to reviewers, GitHub rich diff doesn't render image properly. You can click "view file" from the hamburger button to see the rendered markdown.