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? 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? 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 > >
