1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
|
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.
|
