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 15:10:07 GMT
I'm just saying I don't see how where / how I would find a common API.

I'm supportive of this thought if you find a good common API on a prototype.

Anyway, the issue on that thread is not technical at all.

On Mon, Mar 30, 2015 at 10:51 AM, Jamie G. <jamie.goodyear@gmail.com> wrote:
> If I'm not mistaken, AMQ and HQ configurations are not all too
> different - how does this become recursive? A common API is just an
> adapter layer to everything else, when did abstraction of this form
> become a performance penalty?
>
> Cheers,
> Jamie
>
> On Mon, Mar 30, 2015 at 12:09 PM, Clebert Suconic
> <clebert.suconic@gmail.com> wrote:
>> 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



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

Mime
View raw message