[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] I_Callback
Thomas Bikeev wrote:
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 ...
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/>.
----- Original Message -----
From: "Marcel Ruff" <mr at marcelruff.info>
To: <xmlblaster at server.xmlblaster.org>
Sent: Saturday, November 15, 2003 6:55 PM
Subject: Re: [xmlblaster] I_Callback
How can I prevent my client which implements I_Callback interface to
prematurely before all the updates have been received into callback
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'/>
Here is an example:
1. Start the server
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
-> 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
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
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,
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
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
invocation ignored, we
are shutdown. :Original erroCode=communication.noConnection]