Pluggable *within* ActiveMQ. That is what doesn't exist. The idea is that the underlying engine could be optimized on a case-by-case basis. For instance, you may be able to streamline the implementation of a broker that doesn't require persistence at all. Right now, we have one implementation that tries to be the end-all-be-all solution for everything.
On Wednesday, April 8, 2015, Jim Gomes <jgo...@apache.org> wrote: > I'm with Guillaume on this. From the NMS perspective, the broker already is > a plugin implementation. I don't understand why it would need to go any > deeper than that. NMS can talk to TIBCO or ActiveMQ brokers via one common > API. The idea of pluggable brokers already exists. > > On Mon, Mar 30, 2015, 8:32 AM Guillaume Nodet <gno...@apache.org > <javascript:;>> wrote: > > > Fwiw, the whole broker implementation looks like an implementation detail > > from a user point of view that uses the JMS spec... ;-) > > > > 2015-03-30 17:12 GMT+02:00 Hadrian Zbarcea <hzbar...@gmail.com > <javascript:;>>: > > > > > +1. > > > > > > The blocking today it merely an implementation detail than can be > > > addressed. > > > > > > Hadrian > > > > > > > > > On 03/30/2015 09:23 AM, James Carman 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 > > >> > > >> > > >
