5:32 p.m.
I would like to make a recommendation for logging range IDs for the different components.
Right now, the default width of IDs are 6 characters (they can be more or less, but
that's the default). I'm assuming we all will use HAWK as the prefix (as opposed
to HAWK vs. HAWKMETRICS vs. HAWKALERTS, etc).
Through my experience integrating this logging stuff the past few days in the bus modules,
I've come to appreciate the fact that we should probably give more range than just
1000 IDs to a major component. I don't know exactly how to do it, but I found it
easier to split the ranges up to my subcomponents when using the full 6-characters. This
allows you to create multiple MessageLogger classes (one per maven module is what I think
would be typical - especially if one module doesn't depend on others) and you can
break your main range up into subranges, while still having enough IDs left for actual
logs.
For example, suppose metrics has four subcomponents (and I'm just making this up) -
metrics-aggregator, metrics-collector, metrics-ui, metrics-purge. Now, suppose metrics was
given the range 1000-1999. Each subcomponent would only have 250 IDs each if you assign
them their own subrange. If you don't, if you just give them all 1000 then you will
probably only have a single MessageLogger for all 4, and that will get ugly (MessageLogger
would live in one module, and they all would need to depend on it, and any new log message
would require all modules to recompile, even if the other modules don't need that
message).
So what I say is we give metrics the ID range (e.g.) HAWK-200000 to HAWK-299999. Each
subcomponent could then be given:
metrics-aggregator = 200000-200999
metrics-collector = 201000-201999
metrics-ui = 202000-202999
metrics-purge = 203000-203999
So you can see each still has room for 1,000 message IDs individually with room for 100
subcomponents (that's the first three digits of the ID - 200-299).
Alerts would then be given the range HAWK-300000 to HAWK-399999 and it does the same
thing.
Obviously, this can be tweeked; you can say the first two digits are the component (20-29)
giving you room for 10 subcomponents, with each subcomponent now able to have 10,000
messages (e.g. 200000-209999).
Or we can give each their own prefix (HAWK vs HAWKMETRICS) giving each the full 6-digit ID
range all to themselves.
In any event, if you haven't tried coding up log messages with this Jboss logging
message ID stuff, I suggest you do it, and see what kinds of issues you will see crop up
(mainly it deals with what ranges of IDs get assigned to what MessageLoggers and how many
MessageLoggers do you create and where).
We don't want to do this wrong - it will be headaches later on in the future when we
realize we handed out the IDs ranges poorly or we created MessageLoggers in the wrong
places.
I'm not advocating any specific approach, but we need to think about this - this
isn't one of those things where everyone can go rogue. Unless we give everyone their
own id prefix (HAWK vs. HAWKMETRICS, for example) in which case, go crazy :)