[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[xmlblaster] Re: PTD & Persistence ... le retour ;o)

Marcel Ruff wrote:

cyrille giquello wrote:

Hi Marcel ,
it's again and again the same guy wich is polute your mailbox with the same subject !
;o) So, in some mail I tried to change the subject , for the same eternal problem. At each time you stopped the thread. Like if the subject is horrible ;o)

OK, it is fixed now.

Look at testsuite

xmlBlaster/testsuite/src/java/org/xmlBlaster/test/qos/ TestPtDQueueRedeliver.java

if the test is what you expect.

You can play manually with those helper clients:

java org.xmlBlaster.Main

java javaclients.HelloWorldSubscribe -session.name joeSubscriber/5

java javaclients.HelloWorldPublish -destination joeSubscriber/5 -forceQueuing true -persistent true -numPublish 6 -subscribeable false

to try your use case.

Please report any problems,



What subject ?
When using Persistence Message and Destination Qos with ForceQueuing,
the persistent message file is never erased from filesystem.
To reproduce the problem just make a little modification in
in public void testPtUnknownDestination()
when Construct a message and send it to "Martin Unknown"
just add <isDurable /> in the Qos
code would be like :
// Construct a message and send it to "Martin Unknown"
String xmlKey = "<key oid='' contentMime='text/plain'>\n</key>";
String qos = "<qos> <isDurable /> " // <-- add just this flag
+" <destination queryType='EXACT'>" +receiverName
+" <ForceQueuing />" +
" </destination>"
So, I take my brain and go in the xmlBlaster engine to trace all the operations ...
look at that scenario :
1/ RequestBroker.loadPersistentMessages()
do a publish() of messages found in persistence folder.
2/ RequestBroker.publish()
if (publishQoS.isPubSubStyle()) {
}else if (publishQoS.isPTP_Style()) {
destinationClient.sendUpdate(); // <-- Go there
3/ ClientInfo.sendUpdate()
... client not logged ...
queueMessage(msgUnitWrapper, destination);
4/ ClientInfo.notifyAboutLogin() {
if (messageQueue != null) {
while (true) {
MessageUnitWrapper msgUnitWrapper = messageQueue.pull();
But at any time the PersistenceDriver will be notified that it has to erase a message.
It's why my last posted messages ask for a code guideline to decide where it is possible and the 'right place' to code this notification. I didn't found any idea, because ClientInfo seems to doesn't know the RequestBroker wich handled the persistenceDriver....
Perhaps ClientInfo can send a xmlBlaster message to the RequestBroker engine (without isDurable) to erase this knid of message ?? ;o)
Voilà Marcel ...
It's where I'm blocking when I try to design the system architecture for my current project.
Perhaps Guys who has developped the PersistenceDriver can get a idea about that ?
The rest of xmlBlaster is working fine.
I'll tell you more in few weeks when the project will be in test, online.