Source: libmessage-passing-zeromq-perl
Maintainer: Debian Perl Group <pkg-perl-maintainers@lists.alioth.debian.org>
Uploaders:
 Jonas Smedegaard <dr@jones.dk>,
Section: perl
Testsuite: autopkgtest-pkg-perl
Priority: optional
Build-Depends:
 debhelper-compat (= 13),
 dh-buildinfo,
Build-Depends-Indep:
 libanyevent-perl <!nocheck>,
 libfile-pushd-perl <!nocheck>,
 libjson-perl <!nocheck>,
 libmessage-passing-perl <!nocheck>,
 libmodule-install-perl,
 libmoo-perl <!nocheck>,
 libmoox-types-mooselike-perl <!nocheck>,
 libnamespace-clean-perl <!nocheck>,
 libposix-atfork-perl <!nocheck>,
 libsub-name-perl <!nocheck>,
 libtask-weaken-perl <!nocheck>,
 libtest-simple-perl <!nocheck>,
 libtry-tiny-perl <!nocheck>,
 libzmq-ffi-perl <!nocheck>,
 perl,
Standards-Version: 4.6.0
Vcs-Browser: https://salsa.debian.org/perl-team/modules/packages/libmessage-passing-zeromq-perl
Vcs-Git: https://salsa.debian.org/perl-team/modules/packages/libmessage-passing-zeromq-perl.git
Homepage: https://metacpan.org/release/Message-Passing-ZeroMQ

Package: libmessage-passing-zeromq-perl
Architecture: all
Depends:
 ${misc:Depends},
 ${perl:Depends},
 libanyevent-perl,
 libfile-pushd-perl,
 libmessage-passing-perl,
 libmoo-perl,
 libmoox-types-mooselike-perl,
 libnamespace-clean-perl,
 libposix-atfork-perl,
 libsub-name-perl,
 libtask-weaken-perl,
 libtry-tiny-perl,
 libzmq-ffi-perl,
Description: input and output messages to ZeroMQ
 Message::Passing::ZeroMQ is a ZeroMQ transport for Message::Passing.
 .
 Designed for use as a log transport and aggregation mechanism for perl
 applications, allowing you to aggregate structured and non-structured
 log messages across the network in a non-blocking manner.
 .
 Clients (i.e. users of the Message::Passing::Output::ZeroMQ class)
 connect to a server (i.e. a user of the Message::Passing::Input::ZeroMQ
 class) via ZeroMQ's pub/sub sockets. These are setup to be lossy and
 non-blocking, meaning that if the log-receiver process is down or slow,
 then the application will queue a small (and configurable) amount of
 logs on its side, and after that log messages will be dropped.
 .
 Whilst throwing away log messages isn't a good thing to do, or
 something that you want to happen regularly, in many (especially web
 application) contexts, network logging being a single point of failure
 is not acceptable from a reliability and graceful degradation
 standpoint.
 .
 The application grinding to a halt as a non-essential centralised
 resource is unavailable (e.g. the log aggregation server) is
 significantly less acceptable than the loss of non-essential logging
 data.