activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jamie G." <jamie.goody...@gmail.com>
Subject Re: [PROPOSAL] Pluggable Brokers...
Date Mon, 30 Mar 2015 14:34:49 GMT
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

Mime
View raw message