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
