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

RE: [xmlblaster] polling -> reconnecting - And additional questions



Dear Marcel,

	I still have one question in order to proceed with my work. One
of the conditions to have persistent subscribers is to start a session
with a positive public sessionId, but if I have different clients spread
over the network or even two clients in the same PC (but different
applications) how can I manage the attribution of sessionId without
having conflits.

Best regards,
Eduardo Catarino

PS: Again thanks for your quick answer. 

-----Original Message-----
From: owner-xmlblaster at server.xmlBlaster.org
[mailto:owner-xmlblaster at server.xmlBlaster.org] On Behalf Of Marcel Ruff
Sent: quinta-feira, 22 de Setembro de 2005 21:14
To: xmlblaster at server.xmlBlaster.org
Subject: Re: [xmlblaster] polling -> reconnecting - And additional
questions

Eduardo Catarino wrote:

>Dear Marcel,
>
>	Well I tried and it worked. Thank you very much for your help.
>	However, while I was searching for some help in the
>documentation, I wonder if it is better to implement a solution like
the
>example TestFailSafeAsync.java where the messages have different OID
but
>they are selected by the subscriber using the XPATH. Which solution is
>better?
>  
>
Salute Eduardo,

different OIDs are different topics, they consume memory and eat time to
create and destroy.
So if you have say below 1.000 topics it should be fine, if you have
above say 10.000 you need
to test memory and performance and think about the design.
In most cases, one to ten topics are enough to do to a lot of things,
message instances
can then further be filtered by mime plugins (currently available for
regex, full text xpath, SQL 92 where conditions).
It depends on your use case,

rgds

Marcel

>Best regards,
>Eduardo
>
>-----Original Message-----
>From: owner-xmlblaster at server.xmlBlaster.org
>[mailto:owner-xmlblaster at server.xmlBlaster.org] On Behalf Of Marcel
Ruff
>Sent: quinta-feira, 22 de Setembro de 2005 14:45
>To: xmlblaster at server.xmlBlaster.org
>Subject: Re: [xmlblaster] polling -> reconnecting
>
>Eduardo Catarino wrote:
>
>  
>
>>Hi,
>>
>> 
>>
>>            I have the following problem. I have a simple test 
>>procedure that does this task:
>>
>> 
>>
>> 
>>
>>1)       Start the XmlBlaster server and publish 50 messages
>>
>>2)       Shut down the server
>>
>>3)       Publish again 50 messages
>>
>>4)       Start the server again
>>
>>5)       Send another 50 messages
>>
>> 
>>
>>All the messages have in common the same OID.
>>
>>I can receive all the messages except the ones are sent when the 
>>server is down, in this case I only receive the last one of that
>>    
>>
>group.
>  
>
>>What should I do in order to receive also those messages?
>>
>> 
>>
>>Best regards,
>>
>>Eduardo Catarino
>>
>>    
>>
>I have to add some steps:
>
>1)   Start the XmlBlaster server
>2) Start subscriber
>3) Start publisher and publish 50 messages
>4) Subscriber reveives 50 messages
>5)  Shut down the server
>6)  Publish again 50 messages
>7)  Start the server again
>8)   Send another 50 messages
>9)   Subscriber reconnects and receives 100 messages
>
>A)
>The 50 messages of 6) need to be queued on client side as no server is 
>available.
>This is possible out of the box only with the C++ client library and
the
>
>Java client library.
>Please set the session.name to use a postiv public sessionId, for 
>example "joe/2"
>
>B)
>Further - as on 8) the subscribes is not yet up and running
>it wont receive the messages if not the subscriber did a persistent
>subscribe on 2)
>
>
>Example:
>--------
>java -Dcom.sun.management.jmxremote org.xmlBlaster.Main
>
>java javaclients.HelloWorldPublish -session.name aPublisher/1 
>-numPublish 2000
>
>java javaclients.HelloWorldSubscribe -session.name aSubscriber/1 
>-persistentSubscribe true -multiSubscribe false 
>-dispatch/callback/retries -1
>
>
>With the above command line clients started in 3 DOS-Boxes (xterms) you
>can
>play and simulate easily the above steps.
>
>rgds
>Marcel
>
>
>
>
>
>
>
>
>
>  
>