Re: [xmlblaster] I_Callback

["Thomas Bikeev" <bikeev at gmx.net>]

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