[zeromq-dev] Relation between - HI_WATER_MARK and SEND_BUFFER_SIZE of zmq ?

Santosh N Dumbre santosh.dumbre at igate.com
Tue Aug 21 06:49:55 CEST 2012


Thanks a lot for the reply.

Yes, I do care for messages and want to store them to database(PostgreSql) so that I will not lose messages when  the process crashes.
Is there any existing pattern of zmq that will help me  to store the queued messages to database ?

I want a simple request-reply type application with single client and single server.

The requirement is - The messages should be queued in case of network failure / no receipt of acknowledgement from sever, and should get stored to databse after some limit.

This implementation is to be developed at client-side.

Please let me know if any existing zmq pattern will be of help in this scenario.

Thanks & Regards,
Santosh d.



________________________________
From: zeromq-dev-bounces at lists.zeromq.org [zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Joshua Foster [jhawk28 at gmail.com]
Sent: Saturday, August 18, 2012 6:30 PM
To: ZeroMQ development list
Subject: Re: [zeromq-dev] Relation between - HI_WATER_MARK and SEND_BUFFER_SIZE of zmq ?

HWM is related to the max number of messages in the queue. Send buffer size is related to the max size of the message allowed to send. If HWM is set to infinite (-1), your process will eventually crash. Once it crashes, you lose all the messages in the queue. Do you have some way of recovering? Do you care if you lose messages?

Joshua

[cid:part1.05030201.00070204 at gmail.com]
Santosh N Dumbre<mailto:santosh.dumbre at igate.com>
August 18, 2012 6:55 AM
H i,

I want to develop an client application that will send messages to the server and receive acknowledgments from the server.

The client keep getting data form real-time devices and want to send the same to the server.

The problem is if the network is down, the client application should maintain a Queue of messages and send to server when the network is up and connection becomes active.

It is a single-client to single-server application.

Can this be achieved just by using HI WATER MARK = INFINITE    ?

Can the  HI_WATER_MARK option maintain a message queue which is bigger than size of SEND_BUFFER_SIZE ?

Is there any dependency between HI_WATER_MARK  and SEND_BUFFER_SIZE  of zmq ?

Kindly reply and help.

Thanks,
Sd.



Information contained and transmitted by this e-mail is confidential and proprietary to iGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailadmin at igate.com<mailto:mailadmin at igate.com>. iGATE does not enter into any agreement with any party b y e-mail. Any views expressed by an individual do not necessarily reflect the view of iGATE. iGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While iGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus check s before opening an attachment. To know more about iGATE please visit www.igate.com<http://www.igate.com>.
_______________________________________________
zeromq-dev mailing list
zeromq-dev at lists.zeromq.org<mailto:zeromq-dev at lists.zeromq.org>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120821/e70e4cd0/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: compose-unknown-contact.jpg
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120821/e70e4cd0/attachment.jpg>


More information about the zeromq-dev mailing list