Hello Fraser and thanks for an exhaustive answer.
There are still some foggy parts in this behavior for me, but let me clarify
firstly some parts which were not explained clearly from my side:
* we are connecting to the C++ Qpid broker
* we are really using asynchronous mechanism from Java QMF API:
>From what you have written we might be really the only users using
query+subscribe mechanism :) but we are quite satisfied with it. In
particular, what we do is following:
- create qmfPredicate describing what kind of objects are we interested in
- create subscription based on the query using the predicate
- register subscription to the console
- in the onEvent() callback we receive updates and from the WorkItem we
finally mine the List<QmfConsoleData> with that ObjectId(s) using which we
identify what was changed/deleted/added and store it in our internal
structures
Now why do we have a problem with the 'recycled' ObjectIds. Because of
auditing/monitoring reasons we need to keep track of also deleted objects on
the broker (for some time). Things are more complicated since objects can
reference each other - e.g. binding references queue and exchange it binds
together. However, if the references are the same for deleted and newly
created objects (with the same name) it is quite a challenge to keep track
of what is referencing what.
Of course, if it is given by the broker, there is not too much we can do
about it.
Now, what still puzzles me:
* from the Python I have been using qmf.console API and again it's
asynchronous mechanism to receive object's updates. Briefly:
...Session(self.eventListener, rcvObjects=True, manageConnections=True,
userBindings=True, rcvEvents=True)
...bindClass("org.apache.qpid.broker", "queue")
where eventListener implements objectProps(self, broker, record) and
objectStats(self, broker, record) callbacks. From here I am getting Object
ID:
oid = record.getObjectId()
and here I can see that the ID has a different ('more unique') format: e.g.
the same queue recreated had 0-2-1-0-15440 and later after deletion
0-2-1-0-1592.
I can buy the argument that it uses older QMF1 protocol, but looking into
the code of console.py I can see that it supports both QMF1 + QMF2 and if
the QMF2 is available, the temporary request/response queues created should
have form qmfc-v2-... - which is exactly what I can see on the broker.
This makes me think: is my Python client communicating with QMF1 or QMF2? If
QMF2 why do I see different ObjectId's than in Java QMF if they should be
generated by the broker?
Is there something I am missing?
Thank you.
Cheers,
Michal
--
View this message in context:
http://qpid.2158936.n2.nabble.com/Re-Java-QMF-library-and-ObjectId-tp7613784p7613803.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
