activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clebert Suconic <clebert.suco...@gmail.com>
Subject Re: [PROPOSAL] Pluggable Brokers...
Date Mon, 30 Mar 2015 14:39:46 GMT
The behaviour on how things happen at the server will make it hard to
have a common API.

Second: it gets really recursive. it becomes an extra layer of
abstraction where you need the code as fast as possible.


I'm just saying I don't see how someone could make a single API for
the broker. what would be the pluggable points?

The protocol layer is implemented at the server, storage at the
server...  and they all need Asynchronous implementation. I don't see
a single point where you could plug these behaviours. If we had it we
wouldn't need all this discussion.


On Mon, Mar 30, 2015 at 10:34 AM, Jamie G. <jamie.goodyear@gmail.com> wrote:
> Hi,
>
> Just a quick question on "For instance, when you receive a message,
> activemq is blocking a thread, while it should be asynchronous on the
> server, a callback be sent to the client whenever it was possible,
> from a callback handler.", can you explain this?
>
> Are you referencing synchronized vs actor based/callback code?
>
> How would this impact James' proposal?
>
> Cheers,
> Jamie
>
> On Mon, Mar 30, 2015 at 11:33 AM, Clebert Suconic
> <clebert.suconic@gmail.com> wrote:
>> If there was a semantic behavior in common where this would be
>> possible, we probably wouldn't need any improvements at all.
>>
>> For instance, when you receive a message, activemq is blocking a
>> thread, while it should be asynchronous on the server, a callback be
>> sent to the client whenever it was possible, from a callback handler.
>>
>>
>> It's different how lockings will happen, what makes a common API even
>> more unlikely.
>>
>>
>>
>>
>> Besides, It gets a bit recursive really, implementing an interface to
>> the broker implementing the broker.
>>
>>
>> I'm not saying it's impossible, but it seems unlikely to be possible.
>>
>> On Mon, Mar 30, 2015 at 9:23 AM, James Carman
>> <james@carmanconsulting.com> wrote:
>>> All,
>>>
>>> With all the talk over the last week or so regarding the "Broker
>>> Wars", especially after reading Rob Davies' email about how the broker
>>> has been tweaked through the years to emphasize different aspects
>>> (long-term storage for instance), it occurred to me that we might be
>>> able to move past all this craziness by providing an abstraction layer
>>> above the broker and try to make them "pluggable."
>>>
>>> If there really are situations where the broker needs to focus on one
>>> particular aspect of message delivery, that sounds to me like the
>>> "strategy" pattern.  If a broker can be written in such a way that it
>>> is allowed to focus on certain aspects and maybe ignore or completely
>>> forego others, then it would seem to me that the code could be made
>>> much more straight-forward, because it doesn't have to try to be the
>>> "swiss army knife", solving everyone's problems at one time.
>>>
>>> Of course, this may be just a pipe dream and there's no way to do it
>>> (admittedly I'm not terribly familiar with the code), but I thought
>>> I'd throw it out there as a possible approach.  I mean, we do this
>>> sort of thing already with the persistence providers, so maybe there's
>>> an opportunity here as well.
>>>
>>> Thoughts?
>>>
>>> James
>>
>>
>>
>> --
>> Clebert Suconic
>> http://community.jboss.org/people/clebert.suconic@jboss.com
>> http://clebertsuconic.blogspot.com



-- 
Clebert Suconic
http://community.jboss.org/people/clebert.suconic@jboss.com
http://clebertsuconic.blogspot.com

Mime
View raw message