Hello Marcel,
thanks for the answer: (also thanks for this great product!!!)
here is the whole story - I was trying to implement a small client which would run in the batch mode - i.e. steps 1, 3, 4 as indicated in your email - client should quit once all the updates have been received.
When I am receiving a large number of updates - I was calling disconnect before all the updates have been received
The same behavior I would get with demos:
PtpSend -forceQueuing true -numSend 10 (publishes 10 messages) PtpReceive -abortReceive 5 (retrieves 5 first messages) in this case - repetitive calls to the PtpReceive would deliver again and again 5 messages but not the #6,7,8,9,10 but #4,5,6,7,8 or so.
Now I understand that setting up explicit queue size would be the correct way to proceed to get exactly #1,2,3,4,5 and #6,7,8,9,10.
For my initial requirements - 1) "batch receiver" client should explicitly disconnect and exit(0) after all updates are here. 2) we never know if there are messages and how many
- I will be checking the current number of callback queue entries in the qos before explicitly disconnecting. Is this the correct thing to do for the batch processing?
Yep, but still you have no 'real end', as the publisher keeps on sending ...
Second Question:
If I publish Point to Point(s) - are the steps 1,2,3,4 (as indicated in your answer) - the best practice, or I can actually do 1,3,4 all the time?
In both cases you won't loose any messages it is just that your 'last message' is a virtual assumption. By the way, if you want that the messages survive a server crash (xmlBlaster crash) you need to publish the messages as <persistent/>.
best regards
Marcel
Best Regards, Thomas
----- Original Message ----- From: "Marcel Ruff" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, November 15, 2003 6:55 PM
Subject: Re: [xmlblaster] I_Callback
TB wrote:
Hello,
How can I prevent my client which implements I_Callback interface to
logout
prematurely before all the updates have been received into callback
receiver
plugin?
Hi Thomas,
i think i don't understand the question. Messages are delivered instantly - if there are publishers active there will always be new messages.
You can check the current number of callback queue entries with <qos> <!-- update() --> <queue index='0' of='1'/> </qos>
see
http://www.xmlblaster.org/xmlBlaster/doc/requirements/interface.update.html
Here is an example:
1. Start the server
java org.xmlBlaster.Main
2. Start a subscriber with a positive sessionId
java javaclients.HelloWorldSubscribe -session.name
joe/1 -dispatch/callback/retries -1
Don't hit a key to NOT subscribe explicitly as we publish below a PtP
message
-> Now kill the subscriber with Ctrl-C
3. Start a PtP publisher
java javaclients.HelloWorldPublish -destination joe -forceQueuing
true -numPublish 1000
Hit ten times a key to publish ten messages
4. Start the subscriber from 2. again und you will receive the messages with the queue index count.
A variation is to not do step 2 before step 3. Because the destination
"joe"
is unknown the messages are stored in an instantly created 'subject' queue (note we have set forceQueuing to true). When now 'joe/1' logs in all 10 messages are delivered but in this case the qos queue size may not
be 10
but be some smaller chunks (which sums up to 10) as the subject queue entries are shuffeled to the callback queue and this may be intermitted by the callback sending thread.
The PtP publisher however could mark a message as the last message (setting a QoS client property) but this is transparent to xmlBlaster,
best regards
Marcel
I am trying to use socket protocol and getting:
[14-nov.-2003 13:13:54 INFO MsgErrorHandler-/node/thomas_laptop/client/mon_01/-77] We are the last
session taking care on PtP message
'subject:/node/thomas_laptop/client/mon_01/NORM/10688120348880000 02', putting it back to subject queue [14-nov.-2003 13:13:54 WARN MsgErrorHandler-/node/thomas_laptop/client/mon_01/-77] Callback server
is lost, killing login session of client
callback:/node/thomas_laptop/client/mon_01/-77: XmlBlasterException errorCode=[communication.noConnection.dead] serverSideException=true
node=[thomas_laptop]
location=[SOCKET-HandleClientRequest-mon_01] message=[update()
invocation ignored, we
are shutdown. :Original erroCode=communication.noConnection]
Kind regards, Thomas
-- http://www.xmlBlaster.org
-- http://www.xmlBlaster.org