I think you've misunderstood. The logging system is not meant to be
used
for debugging 0MQ source code. Instead it is meant for debugging the
topology.
Some possible examples of log messages:
- particular endpoint uses invalid wire-level protocol
- particular endpoint is not accessible
Oliver,
Martin Sustrik said the following on 11/19/2010 4:55 AM:
I think there are many possible audiences, however, we haven't yet
figured out who exactly is it going to be.
Thus, the whole system should be open-ended allowing for later addition
of functionality. That's why I alluded to
On 11/17/2010 10:42 AM, Sven Koebnick wrote:
wouldn't it be easiest to just subscribe to regex's instead of fixed
prefix strings?
that shouldn't be too much effort to build into the subscription filter
and would also allow a big deal of other fine stuff.
Well. It means introducing custom
On 11/17/2010 05:58 PM, Oliver Smith wrote:
I would like to pose a question here: who is the target audience the
sys://log transport?
I think there are many possible audiences, however, we haven't yet
figured out who exactly is it going to be.
Thus, the whole system should be open-ended
I would like to pose a question here: who is the target audience the
sys://log transport?
syslog is primarily intended for system administrators. But it seems
like sys://log is more of a debug trail for programmers.
Among many excellent designs by my predecessor here was our product's
logging
On Mon, Nov 15, 2010 at 11:34 PM, Pieter Hintjens p...@imatix.com wrote:
OK, /me found a real keyboard and can explain this better.
Here's my proposal for the topic header:
* Number of repeated characters indicates severity from 1 to 3 (X =
information, XX = warning, XXX = error)
*
Point is that subscription happens on a pure prefix of the topic key.
-Pieter
On 16 Nov 2010 19:01, Erick Tryzelaar erick.tryzel...@gmail.com wrote:
On Mon, Nov 15, 2010 at 11:34 PM, Pieter Hintjens p...@imatix.com wrote:
OK, /me found a real keyboard and can explain this better.
Here's my
i still think this is being clever, rather than just subscribing to the
level you want. for your case, just do two subscribes,
one of \002 and one of \003.
existing practice is for several levels (~7), and do we really want
to count that many out?
On Nov 16, 2010, at 11:19 AM, Pieter Hintjens
On 11/16/2010 07:24 PM, Andrew Hume wrote:
existing practice is for several levels (~7), and do we really want to
count that many out?
+1
Rarely more than 3 levels are used in practice.
Martin
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
It lets you subscribe to both GE severity and EQ category in one go. Yes,
it's being clever... sorry about that. But it makes use simpler IMO. Think
about taking subscriptions from a config file.
Anyhow, I'm pretty sure we don't even need categories here.
-Pieter
On 16 Nov 2010 19:25, Andrew
Hello,
short background (and correct me if something is wrong here):
The sys://log transport is an internal transport, a PUB socket
providing logging information on what happens inside 0MQ. The
information has not yet been defined but probably contains things such
as severity, event type and
Hi Mikko,
short background (and correct me if something is wrong here):
The sys://log transport is an internal transport, a PUB socket
providing logging information on what happens inside 0MQ. The
information has not yet been defined but probably contains things such
as severity, event type
On Nov 15, 2010, at 2:30 PM, Mikko Koppanen wrote:
Hello,
short background (and correct me if something is wrong here):
The sys://log transport is an internal transport, a PUB socket
providing logging information on what happens inside 0MQ. The
information has not yet been defined but
unless you think you need something quite different,
just follow existing practice, e.g. syslog.
that is, a type (== facility) and an impact (==severity==priority).
so i would lay it out as
byte 0 == impact
byte 1 == type
remaining bytes are UTF-8 encoding of message.
don't use multi-part (i
On 11/15/2010 09:57 PM, Andrew Hume wrote:
i agree with martin; differentiate between logging and performance stuff
by the bind address. in fact, we could use this to distinguish versions;
for example, the first format could be sys:/log0, and the next version
can be sys:/log1 and so on. this
On Mon, Nov 15, 2010 at 8:57 PM, Andrew Hume and...@research.att.com wrote:
unless you think you need something quite different,
just follow existing practice, e.g. syslog.
that is, a type (== facility) and an impact (==severity==priority).
so i would lay it out as
byte 0 == impact
byte 1 ==
maybe, although it is a different beast.
(fwiw, i was part of teh original plan 9 team that invented that stuff.)
there are two main lessons here:
1) have the file hierarchy statically/dynamically track the
underlying semantics
2) use byte streams for all communication
for example, the
ordinarily, i would favour this (being a standards geek).
but here, there is no established base and a small population.
and its easy to get new stuff out.
make the protocol lean and clean, and use the bind address to let
users pick which interface they want.
On Nov 15, 2010, at 2:40 PM, Mikko
Oh,
One thing I haven't mentioned: With two distinct endpoints there's no
strict message ordering. The ordering exists only in the scope of a
single endpoint. In other words, each endpoint defines it's own message
stream, completely orthogonal to any other message stream. That, I
think, is a
A simple idea for selection by severity. If severity is a repeated character
string rather than a single byte, you can subscribe to any required level
and higher. Eg. * or ** or *** etc. Since it's an intro transport there is
no real cost. You can use different characters for different categories.
Sorry, that should say 'inproc transport'. My spelling checker got in the
way. Android
On 16 Nov 2010 07:59, Pieter Hintjens p...@imatix.com wrote:
A simple idea for selection by severity. If severity is a repeated
character
string rather than a single byte, you can subscribe to any required
OK, /me found a real keyboard and can explain this better.
Here's my proposal for the topic header:
* Number of repeated characters indicates severity from 1 to 3 (X =
information, XX = warning, XXX = error)
* Character indicates category of error: '?' indicates internal 0MQ
error, '*' indicates
22 matches
Mail list logo
