Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [messaging-dev] New API Requirements Was: Browsing / Streaming...
Agree we need some sort of Session object on the client's implementation.. .but I wouldn't mix that in the API.

I would allow implicit session creation from the API, directly from the connection.

You could have connection.createConsumer (or whatever other name we choose)... connection.createSender (or whatever other name we choose).


And the implementation would do whatever it needs to control its protocol.


For those who still need a transactional usage. we could have it on the optional side.


// don't worry too much about naming here.. we could name it anything we wanted.
TransactionContext context = connection.createTransactionContext()

On Sat, Mar 15, 2025 at 3:40 PM Matt Pavlovich <mattrpav@xxxxxxxxx> wrote:
I’d add that the session adds a bridge of transactionality to link a producer+consumer or consumer+producer (move bad message to DLQ scenario). Additionally, the ability to spin off multiple sessions off a connection and multiple consumers off a session allow apps to “fill the window of latency” for more efficient throughput for certain ack modes. All these layers also complicate configuration of pooling— since spinning up sessions, consumers, and producers can be expensive when performed on a one-per-message basis.

I agree that a unified context that combines the session+producer+consumer would go a long way to reduce unintended misuse of the API. Advanced users can still leverage JMS API for complex scenarios that require fine-grained handling of session, producer, and/or consumer.

However, I think scoping a super-class Context will be a challenge. Having a dynamic producer does not have a lot of practical impact. However, having a dynamic-consumer does— as a consumer attaching to a broker kicks off cursors, prefetch, and other things to get ready to start a feed of messages down to a client. Doing a consumer-per-message creates a lot of thrashing. 

Does the context get locked into a single destination for consuming?  But not producing?  That could be confusing and needs to be worked through.

Matt Pavlovich

On Mar 14, 2025, at 11:09 AM, Clebert Suconic via messaging-dev <messaging-dev@xxxxxxxxxxx> wrote:

The correct contract of a Session is the Threading usage. a Session is supposed to be the interaction of the application with its session.

So, so, not trying to educate everybody on the contract of Session.. just stating the reasoning out loud... (please correct me or add your own reasoning also)

I have two big points on why this is needed:


- Session represents the interaction with threading, as well as transactionality. Which creates a lot of confusion: First objects created from the session can leak into other threads by "user's misuse". 
- Things get even more complex with modern systems using reactive mode and transactionality, making it even more complex to manage.


A better explanation:

back then (20 years ago ;) ), you would do something like this:


Connection connection = connection.createConnection(..... whatever goes in here...);

Session session1 = connection.createSession(.... transaction mode, ack modes... whatever else goes in here...);
Thread thread1 = new MyThread(session1);
thread1.start();

Session session2 = connection.createSession(.... transaction mode, ack modes... whatever else goes in here...);
Thread thread2 = new MyThread(session2);
thread2.start();


If users wrote code like that, it would all work fine.. but it's not that simple any more:

You could create multiple consumers from a single session and send all of them into multiple threads... which is an "against the spec" usage.. and there is no boundaries in the API preventing that type of use.  I lost count of how many times I had to tell users to not do that... and that still happens from time to time.

Session session = connection.createSession(true, Session.SESSION_TRANSACTED); // a transacted session
Consumer consumer1 =  session.createConsumer(session.createQueue("destination1"));
Consumer consumer2 =  session.createConsumer(session.createQueue("destination2"));



MyThread thread = new MYThread(session, consumer1);
thread.start();
MyThread thread2 = new MYThread(session, consumer2);
thread2.start();


class MyThread extends Thread {
    Session session;
    Consumer consumer;

    MyThread(Session session, Consumer consumer) {
        this.session = session;
        this.consumer = consumer;
    }

    public void run () {
                   consumer.receive();
                   if (Random.randomBoolean()) {
                               session.commit();
                   } else {
                               session.rollback();
                  }
    }
}


On this example before... things will get sketchy...  And there's no way to prevent that from the API.. you have to tell users to read a book before they use it.



If we make the Session gone, we could make this more tidy up. 


And I had seen cases like this all the time from users on different messaging systems (JBoss Messaging, then HornetQ, ActiveMQ5, Artemis.... ) I have not seen it in other systems but I'm sure that will happen.

And this also represents a big challenge for API suppliers as it's a big incognito on what to do.


On Fri, Mar 14, 2025 at 11:06 AM David Blevins <david.blevins@xxxxxxxxx> wrote:


On Mar 14, 2025, at 7:38 AM, Clebert Suconic via messaging-dev <messaging-dev@xxxxxxxxxxx> wrote:

If needed I can list a number of reasons for removing the Session concept. At this point I think it's obvious and if someone disagrees I can list the reasoning here.

Please do.  Not out of disagreement, but so we have something the world can reference to understand our motivation for any potential new API design.  I'd encourage you also to put that level of detail in the readme of any items added to the messaging-proposal repo.


 Think of that repo as a JEP.  Not quite as detailed, but should provide some level of understanding.

-David

On Thu, Mar 13, 2025 at 4:56 PM Matt Pavlovich <mattrpav@xxxxxxxxx> wrote:

Having a single way to receive anything in terms of Messaging would be a dream come true :)

Love it!  Let’s do it ;-)


On Thu, Mar 13, 2025 at 4:03 PM Matt Pavlovich <mattrpav@xxxxxxxxx> wrote:

At this point it seems to a good idea to have these two concepts differentiated... Queuing and Streaming..  

Why do you think it should be differentiated? What is the difference to a coded application to handle this that couldn’t be handled in a configuration flag instead of a change in class used in the API?  The original JMS API had this same type of paradigm that became an issue when using topic v queue. This approach required a code-change to switch destination types instead of being able to adjust a config value.

I think it would be better to have a simplified API that is a reader and the only difference if you want stream (no ack) or read (ack) is some sort of config flag or ack mode.

Thanks,
Matt Pavlovich

On Thu, Mar 13, 2025 at 11:09 AM Reza Rahman via messaging-dev <messaging-dev@xxxxxxxxxxx> wrote:
I would first need to understand more about the use case to be honest.

Is this the same as the existing browsing use case or is it actually consuming messages off a queue? If the latter, this would be an imperative alternative to MDB style declarative message consumption?

From: messaging-dev <messaging-dev-bounces@xxxxxxxxxxx> on behalf of Clebert Suconic via messaging-dev <messaging-dev@xxxxxxxxxxx>
Sent: Thursday, March 13, 2025 11:00 AM
To: Matt Pavlovich <mattrpav@xxxxxxxxx>
Cc: Clebert Suconic <csuconic@xxxxxxxxxx>; EE4J Messaging project developer discussions <messaging-dev@xxxxxxxxxxx>
Subject: Re: [messaging-dev] Browsing / Streaming...
 
well.. you have things on a certain context... 

you could maybe even reuse some of the Java Streams API, expand perhaps?

On Thu, Mar 13, 2025 at 10:43 AM Matt Pavlovich <mattrpav@xxxxxxxxx> wrote:
Naming is hard! The first thing that jumped out at me is that ’streaming’ is confused with the Java ’streams’ language feature. I lean towards ‘Event’ since it is shorter (and not as over loaded).

Matt Pavlovich

> On Mar 12, 2025, at 2:40 PM, Clebert Suconic via messaging-dev <messaging-dev@xxxxxxxxxxx> wrote:
>
> I'm planning to spend some time next week writing some ideas...
>
>
> But before I spend time on it.. I wanted to ask something...
>
>
> There's the concept of a Browser in the current JMS API. What if we called it Streaming?
>
> You would have a differentiation between Queueing semantics (single destination polling messages between multiple endpoints) and Streaming semantics where all the messages from the destinations are received.
>
> It's the same concept in the end.. but maybe Streaming would be a better name for a newer API.
>
>
>
> _______________________________________________
> messaging-dev mailing list
> messaging-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://accounts.eclipse.org

_______________________________________________
messaging-dev mailing list
messaging-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
_______________________________________________
messaging-dev mailing list
messaging-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org


_______________________________________________
messaging-dev mailing list
messaging-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org

_______________________________________________
messaging-dev mailing list
messaging-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org

Back to the top