Ubuntu
libmessage-passing-zeromq-perl package

libmessage-passing-zeromq-perl 0.010-2 source package in Ubuntu

Changelog

libmessage-passing-zeromq-perl (0.010-2) unstable; urgency=medium

  * Team upload.
  * Fix autopkgtests. Don't run smoke tests from t/author/.

 -- gregor herrmann <email address hidden>  Wed, 02 Aug 2017 10:46:30 -0400

Upload details

Uploaded by:
Debian Perl Group
Uploaded to:
Sid
Original maintainer:
Debian Perl Group
Architectures:
all
Section:
misc
Urgency:
Medium Urgency

See full publishing history Publishing

Series Pocket Published Component Section
Focal release universe misc
Bionic release universe misc

Builds

Artful: [FULLYBUILT] amd64

Downloads

File Size SHA-256 Checksum
libmessage-passing-zeromq-perl_0.010-2.dsc 2.5 KiB 15f5c4388d257b5a1e6c5ec9e1a8f33fa1986d86a381b64c3694376deab2cdd8
libmessage-passing-zeromq-perl_0.010.orig.tar.gz 27.9 KiB 34b325b2f5bcea9e38bc680e79a7737de31429b7be32b18ff9c0b55ab0ae7380
libmessage-passing-zeromq-perl_0.010-2.debian.tar.xz 14.5 KiB 4467edf20a5e0aff9beb49af0275244609dddee0beda20ab2e090b8851492382

Available diffs

No changes file available.

Binary packages built by this source

libmessage-passing-zeromq-perl: 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.