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

Re: [xmlblaster] I_Callback

Thomas Bikeev wrote: 
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" <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 

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