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. <[email protected]> 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 > <[email protected]> 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 >> <[email protected]> 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/[email protected] >> http://clebertsuconic.blogspot.com -- Clebert Suconic http://community.jboss.org/people/[email protected] http://clebertsuconic.blogspot.com
