On 25 March 2013 21:27, Fraser Adams <[email protected]> wrote:

> On 25/03/13 19:47, Rob Godfrey wrote:
>
>> In the meantime have you got a list of all the areas where the Java
>> Broker and C++ broker are incompatible?  I'm sure Gordon and I wouldbe
>> very interested in that and would do our utmost to try to narrow that
>> gap.
>>
>> Thanks again,
>> Rob
>>
>>  Hi Rob, I'm afraid that I haven't got a full list as yet. The good news
> is that an awful lot is pretty similar. I noted some gaps in the Session
> objects in the Java broker - IIRC I think it was linking between session,
> subscription and queue. It's a little detail but it's useful in my GUI I
> can start with a connection and navigate through session and subscription
> to queue and vice versa I can start with a queue and navigate to
> connection. I suspect that I may be the only person who actually uses this
> behaviour :-D but I've also used it in another place where I audit queues
> and if someone tries to create or connect to a queue I don't have in a
> whitelist I log the connection information. Clearly I can't do that with
> the Java broker with this little piece of linkage missing. To be fair it's
> only really 'cause the Java broker model is a work in progress and it's
> marked as "TODO".
>
> OK - I haven't looked at the Java code for that in a while (even though
there's a fair chance that I was the guilt party who wrote it - others
(Robbie, Alex, etc) tend to be far more conscientious about these things).
Raise a JIRA if it is causing an issue, and we (I) will try to fix it
sharpish :-)


> The main differences that I think cause pain is in the Queue object. It
> looks like there are a lot of differences between the Queue definitions for
> the C++ and Java brokers. For starters no ring queue in the Java broker (I
> use that all the time) but other differences relate to the fact that all
> the little config options seem to be different.
>

I found a list here https://cwiki.apache.org/**confluence/display/qpid/Qpid+
> **extensions+to+AMQP<https://cwiki.apache.org/confluence/display/qpid/Qpid+extensions+to+AMQP>


Ah yes, I can vaguely recall creating that page a *long* time ago :-)


> I don't know how complete it currently is but skimming through it it looks
> consistent with what I've noted. As you can see the bulk of the differences
> are in Queue.Declare. Clearly this also means that AddressStrings can't
> really be used interoperably between the two brokers - at least with the
> management interface it's possible to "shim" to some degree between QMF and
> the Java broker internal model to try to expose some level of commonality
> clearly that won't fix it when AddressStrings are being used.
>
>
We should definitely try to address the cases where queue arguments simply
have different names.  Things like ring queues are a little odd.  In the
C++ broker they make a lot of sense because of the design of the persistent
store in use. Because the design of the store in the Java Broker is so
different it makes less sense to implement them in the same way... but
having some sort of size bounded queue would make sense... and we should
aim to provide a single name for this so they can be created consistently
across the two implementations.


> I was planning on having a go adding stuff to the Java broker
> ConfiguredObjects when I'd got the other stuff committed, but the plugin
> changes and the questions about where to put the Java QMF stuff are likely
> to delay that a little.
>
>
Again - apologies for this. Robbie is probably best placed to say when the
APIs are definitely "stable"... but when you check your stuff in we should
definitely make sure it is part of the Jenkins CI build so that if further
changes are made to the API we don't break the management code when we
check in such changes (or if we do we fix it ASAP).

Cheers,
Rob


> Frase
>
>
>
>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: 
> [email protected].**org<[email protected]>
> For additional commands, e-mail: [email protected]
>
>

Reply via email to