Re: continuous query - high availability and assurance

2017-08-15 Thread Udo Kohlmeyer

Hi there Roi,

If you have turned on Durable Client-Server messaging 
 
then the cluster should deal with the failure of a client. All client 
bound messages would have a "at-least-once" delivery policy. All 
client-bound messages are acknowledged asynchronously after delivery to 
the client.


If you have enabled "subscription-redundancy" on the client pool and set 
it to either -1 or any number > 0, then the server nodes will have 
redundant client queues, which will enable to server cluster to handle 
the case where the client-queue is lost due to the server having failed. 
see documentation 



As stated above, client messages are delivered to the client from the 
server. The acknowledgement upon receiving these messages are done in an 
asynchronous manner back to the server. There is no manual intervention 
required to acknowledge the receiving of the messages. In addition to 
this you cannot apply the messaging paradigm where you want to only 
acknowledge a message AFTER the processing of that message by the 
application.


A client message (CQ or subscription) will be available for 
acknowledgement upon successful delivery to the client and not the 
custom processing of the message by the application.


--Udo



On 8/15/17 10:25, Mark Bretl wrote:

+ user

On Tue, Aug 15, 2017 at 10:17 AM, Roi Apelker 
wrote:


Hi,

I have been working on an issue related to continuous query mechanism, and
I would like to know if this mechanism, with High availability, assures
100% data integrity?

For example, if I have 2 nodes where a client registered to CQ, and one
node fails, is there any scenario, in which a notification might be lost,
either not sent at all, or hasn’t reached its destination and will not be
sent, or any other?

Is there a guarantee that all information pertinent for the CQ will reach
the subscriber?

Thanks,

Roi
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer <
https://www.amdocs.com/about/email-disclaimer>





Re: continuous query - high availability and assurance

2017-08-15 Thread Mark Bretl
+ user

On Tue, Aug 15, 2017 at 10:17 AM, Roi Apelker 
wrote:

> Hi,
>
> I have been working on an issue related to continuous query mechanism, and
> I would like to know if this mechanism, with High availability, assures
> 100% data integrity?
>
> For example, if I have 2 nodes where a client registered to CQ, and one
> node fails, is there any scenario, in which a notification might be lost,
> either not sent at all, or hasn’t reached its destination and will not be
> sent, or any other?
>
> Is there a guarantee that all information pertinent for the CQ will reach
> the subscriber?
>
> Thanks,
>
> Roi
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at https://www.amdocs.com/about/email-disclaimer <
> https://www.amdocs.com/about/email-disclaimer>
>


continuous query - high availability and assurance

2017-08-15 Thread Roi Apelker
Hi,

I have been working on an issue related to continuous query mechanism, and I 
would like to know if this mechanism, with High availability, assures 100% data 
integrity?

For example, if I have 2 nodes where a client registered to CQ, and one node 
fails, is there any scenario, in which a notification might be lost, either not 
sent at all, or hasn’t reached its destination and will not be sent, or any 
other? 

Is there a guarantee that all information pertinent for the CQ will reach the 
subscriber?

Thanks,

Roi
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer