[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] I_Callback
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?
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?
----- 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
> TB wrote:
> > Hello,
> > How can I prevent my client which implements I_Callback interface to
> > prematurely before all the updates have been received into callback
> > 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'/>
> 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
> -> 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,
> best regards
> > 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
> > location=[SOCKET-HandleClientRequest-mon_01] message=[update()
invocation ignored, we
> > are shutdown. :Original erroCode=communication.noConnection]
> > Kind regards,
> > Thomas