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
|
Source: libmessage-passing-zeromq-perl
Section: perl
Priority: optional
Build-Depends: cdbs,
devscripts,
perl,
debhelper,
dh-buildinfo,
libanyevent-perl,
libfile-pushd-perl,
libmessage-passing-perl,
libmoo-perl,
libposix-atfork-perl,
libsub-name-perl,
libtask-weaken-perl,
libtry-tiny-perl,
libzmq-ffi-perl,
libnamespace-clean-perl,
libmoox-types-mooselike-perl,
libtest-simple-perl
Maintainer: Debian Perl Group <pkg-perl-maintainers@lists.alioth.debian.org>
Uploaders: Jonas Smedegaard <dr@jones.dk>
Standards-Version: 3.9.8
Vcs-Git: https://anonscm.debian.org/git/pkg-perl/packages/libmessage-passing-zeromq-perl
Vcs-Browser: https://anonscm.debian.org/cgit/pkg-perl/packages/libmessage-passing-zeromq-perl.git
Homepage: http://search.cpan.org/dist/Message-Passing-ZeroMQ/
Package: libmessage-passing-zeromq-perl
Architecture: all
Depends: ${cdbs:Depends},
${misc:Depends},
${perl:Depends}
Recommends: ${cdbs:Recommends}
Suggests: ${cdbs:Suggests}
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.
|
