You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Gregg Wonderly (JIRA)" <ji...@apache.org> on 2007/03/02 22:18:50 UTC
[jira] Created: (RIVER-13) net.jini.discovery.LookupDiscovery
logging is verbose and distracting to debugging
net.jini.discovery.LookupDiscovery logging is verbose and distracting to debugging
----------------------------------------------------------------------------------
Key: RIVER-13
URL: https://issues.apache.org/jira/browse/RIVER-13
Project: River
Issue Type: Improvement
Environment: Any Machine with multiple network interfaces, some of which are not active.
Reporter: Gregg Wonderly
On my laptop computer, I have 3 different network interfaces available. Wireless, wired and bluetooth. When trying to debug certain LookupDiscovery issues, I wanted to turn logging up to the FINE level. Apon doing this, I was suddenly greeted with huge amounts of logging related to the inactive interfaces not being able to use multicast. On top of that, the logger used seems to not be setup correctly.
Below is an extraction of the log file showing the two, recurring log entries. The HANDLED entry has a "null" logger name, which makes it difficult to know how to turn that entry on/off.
03/02/2007 15:05:39 [net.jini.discovery.LookupDiscovery#29] CONFIG # LookupDiscovery - multicast network interface(s): [name:lo (MS TCP Loopback interface) index: 1 addresses:
/127.0.0.1;
, name:eth0 (Realtek RTL8139/810x Family Fast Ethernet NIC - Packet Scheduler Miniport) index: 2 addresses:
, name:eth1 (Bluetooth Device (Personal Area Network) #3) index: 65541 addresses:
, name:eth2 (Broadcom 802.11b/g WLAN - Packet Scheduler Miniport) index: 1507331 addresses:
/192.168.5.104;
]
03/02/2007 15:05:39 [null#30] HANDLED # network interface is bad or not configured for multicast: name:eth0 (Realtek RTL8139/810x Family Fast Ethernet NIC - Packet Scheduler Miniport) index: 2 addresses:
java.net.SocketException: bad argument for IP_MULTICAST_IF2: No IP addresses bound to interface
at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method)
at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299)
at java.net.MulticastSocket.setNetworkInterface(MulticastSocket.java:502)
at net.jini.discovery.LookupDiscovery$AnnouncementListener.<init>(LookupDiscovery.java:1033)
at net.jini.discovery.LookupDiscovery$7.run(LookupDiscovery.java:3102)
at java.security.AccessController.doPrivileged(Native Method)
at net.jini.security.Security$5.run(Security.java:543)
at java.security.AccessController.doPrivileged(Native Method)
at net.jini.security.Security.doPrivileged(Security.java:540)
at net.jini.discovery.LookupDiscovery.beginDiscovery(LookupDiscovery.java:3100)
at net.jini.discovery.LookupDiscovery.<init>(LookupDiscovery.java:1957)
at net.jini.discovery.LookupDiscoveryManager.beginDiscovery(LookupDiscoveryManager.java:1493)
at net.jini.discovery.LookupDiscoveryManager.<init>(LookupDiscoveryManager.java:936)
I'd like to recommend a hierarchy of loggers be used in this code. I think that there would be some value in having the discovery logging support loggers with suffixes such as
...unicast.eth0
...multicast.eth0
or
...eth0.multicast
...eth0.unicast
to help the user be able to turn off unneed logging information. I'm not sure exactly what logger names make the most sense, but I think something with more information in the logger name would be helpful in managing the logging output more effectively.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (RIVER-13) net.jini.discovery.LookupDiscovery
logging is verbose and distracting to debugging
Posted by Mark Brouwer <ma...@cheiron.org>.
Hi Gregg,
I don't know whether you have much experience with JIRA, but JIRA
supports rich text formatting (kind of Wiki style) that allows you to
make issue reports a bit more readable.
With the formatting options such as {noformat}text{noformat} you can
display your stacktraces, etc. in a readable way. Have a look at
http://jira.atlassian.com/secure/WikiRendererHelpAction.jspa?section=advanced
if you want to make use of it.
--
Mark
Re: [jira] Commented: (RIVER-13) net.jini.discovery.LookupDiscovery
logging is verbose and distracting to debugging
Posted by Mark Brouwer <ma...@cheiron.org>.
Craig L Russell wrote:
>
> On Mar 4, 2007, at 3:20 PM, Gregg Wonderly wrote:
>> Mark Brouwer wrote:
>
>>> and I want to apply a filter so that only log record with a level of
>>> exactly FINEST are logged for discovery
>
> IIUC, you can never specify that only log records with FINEST are
> logged. FINEST means to log all records that are equal to or more
> important, including FINER, FINE, INFO, WARN, and SEVERE.
You can Craig, but you have to implement a java.util.logging.Filter (so
where I use "filter" I mean "applying a Filter"). I have a filter that
filters LogRecords of which the level is within a particular range so
you can also say: log all records of which the level is in the range of
FINEST - FINER, and believe it or not I've used them ;-)
You can also create filter chains that operate as AND/OR operations in
which you capture multiple dimension to which you want to look at your
log records.
--
Mark
Re: [jira] Commented: (RIVER-13) net.jini.discovery.LookupDiscovery
logging is verbose and distracting to debugging
Posted by Craig L Russell <Cr...@Sun.COM>.
On Mar 4, 2007, at 3:20 PM, Gregg Wonderly wrote:
> Mark Brouwer wrote:
>> and I want to apply a filter so that only log record with a level of
>> exactly FINEST are logged for discovery
IIUC, you can never specify that only log records with FINEST are
logged. FINEST means to log all records that are equal to or more
important, including FINER, FINE, INFO, WARN, and SEVERE.
Craig
Craig Russell
DB PMC
clr@apache.org http://db.apache.org/jdo
Re: [jira] Commented: (RIVER-13) net.jini.discovery.LookupDiscovery
logging is verbose and distracting to debugging
Posted by Mark Brouwer <ma...@cheiron.org>.
Gregg Wonderly wrote:
> Mark Brouwer wrote:
>> Assume we change the hierarchy from:
>>
>> n.j.d.LookupDiscovery
>>
>> to
>>
>> n.j.d.LookupDiscovery.eth0.unicast
>> n.j.d.LookupDiscovery.eth0.multicast
>> n.j.d.LookupDiscovery.eth1.unicast
>> n.j.d.LookupDiscovery.eth1.multicast
>>
>> and I want to apply a filter so that only log record with a level of
>> exactly FINEST are logged for discovery then I can't no longer apply
>> that filter on the logger named "LookupDiscovery".
>
> The existing implementation of the java.util.logging allows you to say
>
> net.jini.discovery.LookupDiscovery.level=FINEST
>
> and that covers all in the hierarchy of names beyond that name. Are you
> referring to your filter mechanism that doesn't match the hierarchy?
Sorry for not being clear Gregg, another try.
I'm referring to an implementation of java.util.logging.Filter [1] that
is executed in the java.util.logging.Logger.log(LogRecord) method.
Opposed to the log level a filter are not inherited by a Logger from the
nearest parent that has a non-null Filter (semantics of Logger, so I'm
not deviating from the spec here).
When you create a deeper hierarchy of loggers for LookupDiscovery I
can't set these filters anymore on the LookupDiscovery node as the
logging will take place (at least that is what I assume) at a node that
is a child of LookupDiscovery, meaning I have to start setting filters
on each child node and that is my 'resistance' to a hierarchy in the
loggers for LookupDiscovery.
[1] Seven provides various implementation of java.util.logging.Filter
that can easily be applied to the logger nodes or log handlers, an
example is a regular expression filter so you can prevent from log
records that contain something like "network interface is bad" in their
message from being displayed. These can be applied during runtime to
troubleshoot.
BTW can you indicate whether when all the output is suppressed from the
incorrect configured or not disabled interfaces whether you still want
to have more hierarchy in the loggers.
> Also, my logman.dev.java.net project has an example formatter that is
> used for logrecords displayed in its serviceUI. One setting of
> properties for the formatter causes it to display
> [n.j.d.LookupDiscovery]. It uses the first letter of all the components
> of the name except the last to shorten the display width.
Also neat feature Gregg, going to remember that one too, although there
is a chance of ambiguity when shortening the package names, but I guess
most times it won't be a problem.
--
Mark
Re: [jira] Commented: (RIVER-13) net.jini.discovery.LookupDiscovery
logging is verbose and distracting to debugging
Posted by Gregg Wonderly <gr...@wonderly.org>.
Mark Brouwer wrote:
> Assume we change the hierarchy from:
>
> n.j.d.LookupDiscovery
>
> to
>
> n.j.d.LookupDiscovery.eth0.unicast
> n.j.d.LookupDiscovery.eth0.multicast
> n.j.d.LookupDiscovery.eth1.unicast
> n.j.d.LookupDiscovery.eth1.multicast
>
> and I want to apply a filter so that only log record with a level of
> exactly FINEST are logged for discovery then I can't no longer apply
> that filter on the logger named "LookupDiscovery".
The existing implementation of the java.util.logging allows you to say
net.jini.discovery.LookupDiscovery.level=FINEST
and that covers all in the hierarchy of names beyond that name. Are you
referring to your filter mechanism that doesn't match the hierarchy?
Also, my logman.dev.java.net project has an example formatter that is used for
logrecords displayed in its serviceUI. One setting of properties for the
formatter causes it to display [n.j.d.LookupDiscovery]. It uses the first
letter of all the components of the name except the last to shorten the display
width.
Gregg Wonderly
Re: [jira] Commented: (RIVER-13) net.jini.discovery.LookupDiscovery
logging is verbose and distracting to debugging
Posted by Mark Brouwer <ma...@cheiron.org>.
Hi Gregg,
Gregg Wonderly (JIRA) wrote:
> Gregg Wonderly commented on RIVER-13:
> -------------------------------------
>
> Right, I see that the logger name is not set. I do use a customer formatter as
> the attached log entry indicates. It includes the logger name so
that you can
> know what to turn down in log levels to stop a particular logger that
is too
> verbose.
>
> I'm not sure of all the potential benefits of a hierarchy. Here are some:
> {noformat}
> o As I've discussed above, allow for messages with unused interfaces to be
> turned completely off.
> o Allow a particular interface's messages to be routed through a particular
> handler.
> {noformat}
Some more lessons in pretty issue formatting ;-) JIRA also supports
lists, by putting the star character on a new line in front of a list
item, 2 star characters for another level of indentation, etc.
* item 1
* item 2
** item 1 for item 2
** item 2 for item 2
* item 3
You see in the end a JIRA issue can become as pretty as a Wikipedia page ...
BTW each field in JIRA that can take Wikipedia style formatting has a
preview icon and help icon to the right. By clicking preview you can see
the result of what you have edited and the help pops-up a window
explaining all the formatting options.
> I'm not sure how others use the logger name, but I use it for a wide
> range of information and control in my applications. I really find
> value in having differentiation by logger name when logging applies
> to devices or external entities that might be the responsibility of
> different people or different organizations.
What I've seen is that most people use SimpleFormatter as it is the
default and that one doesn't display the logger name. I must admit
though a formatter that displays the logger name is a neat one, I'm
going to remember that. I guess most people have to rely on
documentation of which loggers they can turn on or off, etc.
FWIW in case of Seven I have an array of tools to filter such as
level range, type of exceptions, message content (regular expressions)
and service context, the latter is important if you have multiple
instances of services that use e.g. LookupDiscovery and you want to
display only the log records that are caused by that service.
And there lies to me the problem I have with hierarchy of loggers, I
tend to use them for subsystems in a piece of software and rely on other
means for filtering. If the hierarchy alone must be sufficient for
filtering then there are a lot of dimensions you want to capture in the
hierarchy and I'm afraid that won't be easy as people always tend to
look at things from different angles, also requirements change depending
on the problem you want to tackle or information to obtain.
Implementing your suggestion is likely not going to bring any help to
those stuck with SimpleFormatter (my guess most of the people) as it
would require a lot of explanation to help them pick the proper logger
name to turn it off. I'm inclined to see more value in making sure you
are not swamped by log messages for which the chance is 99% the problem
is not going away any time soon.
Likely introducing a hierarchy is not of any harm for most people who
don't want to make use of the finer granularity of the logger names
involved, but there is one serious drawback I can see for those
utilizing log filtering features.
Assume we change the hierarchy from:
n.j.d.LookupDiscovery
to
n.j.d.LookupDiscovery.eth0.unicast
n.j.d.LookupDiscovery.eth0.multicast
n.j.d.LookupDiscovery.eth1.unicast
n.j.d.LookupDiscovery.eth1.multicast
and I want to apply a filter so that only log record with a level of
exactly FINEST are logged for discovery then I can't no longer apply
that filter on the logger named "LookupDiscovery". I have to apply it to
all the 4 loggers, or even more when there are more than 2 interfaces.
This is due to the fact that filtering is only applied to a log record
on the Logger instance to which the LogRecord is presented, down the
hierarchy filtering doesn't work [1].
As you can see introducing an hierarchy can also make it harder to
perform filtering, therefore I'm very reluctant to introduce such an
hierarchy.
[1] assuming semantics of java.util.logging.Logger and not a subclass
that might provide different behavior.
--
Mark
[jira] Commented: (RIVER-13) net.jini.discovery.LookupDiscovery
logging is verbose and distracting to debugging
Posted by "Gregg Wonderly (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477709 ]
Gregg Wonderly commented on RIVER-13:
-------------------------------------
Right, I see that the logger name is not set. I do use a customer formatter as the attached log entry indicates. It includes the logger name so that you can know what to turn down in log levels to stop a particular logger that is too verbose.
I'm not sure of all the potential benefits of a hierarchy. Here are some:
{noformat}
o As I've discussed above, allow for messages with unused interfaces to be
turned completely off.
o Allow a particular interface's messages to be routed through a particular handler.
{noformat}
I'm not sure how others use the logger name, but I use it for a wide range of information and control in my applications. I really find value in having differentiation by logger name when logging applies to devices or external entities that might be the responsibility of different people or different organizations.
> net.jini.discovery.LookupDiscovery logging is verbose and distracting to debugging
> ----------------------------------------------------------------------------------
>
> Key: RIVER-13
> URL: https://issues.apache.org/jira/browse/RIVER-13
> Project: River
> Issue Type: Improvement
> Environment: Any Machine with multiple network interfaces, some of which are not active.
> Reporter: Gregg Wonderly
>
> On my laptop computer, I have 3 different network interfaces available. Wireless, wired and bluetooth. When trying to debug certain LookupDiscovery issues, I wanted to turn logging up to the FINE level. Apon doing this, I was suddenly greeted with huge amounts of logging related to the inactive interfaces not being able to use multicast. On top of that, the logger used seems to not be setup correctly.
> Below is an extraction of the log file showing the two, recurring log entries. The HANDLED entry has a "null" logger name, which makes it difficult to know how to turn that entry on/off.
> 03/02/2007 15:05:39 [net.jini.discovery.LookupDiscovery#29] CONFIG # LookupDiscovery - multicast network interface(s): [name:lo (MS TCP Loopback interface) index: 1 addresses:
> /127.0.0.1;
> , name:eth0 (Realtek RTL8139/810x Family Fast Ethernet NIC - Packet Scheduler Miniport) index: 2 addresses:
> , name:eth1 (Bluetooth Device (Personal Area Network) #3) index: 65541 addresses:
> , name:eth2 (Broadcom 802.11b/g WLAN - Packet Scheduler Miniport) index: 1507331 addresses:
> /192.168.5.104;
> ]
> 03/02/2007 15:05:39 [null#30] HANDLED # network interface is bad or not configured for multicast: name:eth0 (Realtek RTL8139/810x Family Fast Ethernet NIC - Packet Scheduler Miniport) index: 2 addresses:
> java.net.SocketException: bad argument for IP_MULTICAST_IF2: No IP addresses bound to interface
> at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method)
> at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299)
> at java.net.MulticastSocket.setNetworkInterface(MulticastSocket.java:502)
> at net.jini.discovery.LookupDiscovery$AnnouncementListener.<init>(LookupDiscovery.java:1033)
> at net.jini.discovery.LookupDiscovery$7.run(LookupDiscovery.java:3102)
> at java.security.AccessController.doPrivileged(Native Method)
> at net.jini.security.Security$5.run(Security.java:543)
> at java.security.AccessController.doPrivileged(Native Method)
> at net.jini.security.Security.doPrivileged(Security.java:540)
> at net.jini.discovery.LookupDiscovery.beginDiscovery(LookupDiscovery.java:3100)
> at net.jini.discovery.LookupDiscovery.<init>(LookupDiscovery.java:1957)
> at net.jini.discovery.LookupDiscoveryManager.beginDiscovery(LookupDiscoveryManager.java:1493)
> at net.jini.discovery.LookupDiscoveryManager.<init>(LookupDiscoveryManager.java:936)
> I'd like to recommend a hierarchy of loggers be used in this code. I think that there would be some value in having the discovery logging support loggers with suffixes such as
> ...unicast.eth0
> ...multicast.eth0
> or
> ...eth0.multicast
> ...eth0.unicast
> to help the user be able to turn off unneed logging information. I'm not sure exactly what logger names make the most sense, but I think something with more information in the logger name would be helpful in managing the logging output more effectively.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (RIVER-13) net.jini.discovery.LookupDiscovery
logging is verbose and distracting to debugging
Posted by "Mark Brouwer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Brouwer updated RIVER-13:
------------------------------
Component/s: net_jini_discovery
Affects Version/s: jtsk_2.1
> net.jini.discovery.LookupDiscovery logging is verbose and distracting to debugging
> ----------------------------------------------------------------------------------
>
> Key: RIVER-13
> URL: https://issues.apache.org/jira/browse/RIVER-13
> Project: River
> Issue Type: Improvement
> Components: net_jini_discovery
> Affects Versions: jtsk_2.1
> Environment: Any Machine with multiple network interfaces, some of which are not active.
> Reporter: Gregg Wonderly
>
> On my laptop computer, I have 3 different network interfaces available. Wireless, wired and bluetooth. When trying to debug certain LookupDiscovery issues, I wanted to turn logging up to the FINE level. Apon doing this, I was suddenly greeted with huge amounts of logging related to the inactive interfaces not being able to use multicast. On top of that, the logger used seems to not be setup correctly.
> Below is an extraction of the log file showing the two, recurring log entries. The HANDLED entry has a "null" logger name, which makes it difficult to know how to turn that entry on/off.
> 03/02/2007 15:05:39 [net.jini.discovery.LookupDiscovery#29] CONFIG # LookupDiscovery - multicast network interface(s): [name:lo (MS TCP Loopback interface) index: 1 addresses:
> /127.0.0.1;
> , name:eth0 (Realtek RTL8139/810x Family Fast Ethernet NIC - Packet Scheduler Miniport) index: 2 addresses:
> , name:eth1 (Bluetooth Device (Personal Area Network) #3) index: 65541 addresses:
> , name:eth2 (Broadcom 802.11b/g WLAN - Packet Scheduler Miniport) index: 1507331 addresses:
> /192.168.5.104;
> ]
> 03/02/2007 15:05:39 [null#30] HANDLED # network interface is bad or not configured for multicast: name:eth0 (Realtek RTL8139/810x Family Fast Ethernet NIC - Packet Scheduler Miniport) index: 2 addresses:
> java.net.SocketException: bad argument for IP_MULTICAST_IF2: No IP addresses bound to interface
> at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method)
> at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299)
> at java.net.MulticastSocket.setNetworkInterface(MulticastSocket.java:502)
> at net.jini.discovery.LookupDiscovery$AnnouncementListener.<init>(LookupDiscovery.java:1033)
> at net.jini.discovery.LookupDiscovery$7.run(LookupDiscovery.java:3102)
> at java.security.AccessController.doPrivileged(Native Method)
> at net.jini.security.Security$5.run(Security.java:543)
> at java.security.AccessController.doPrivileged(Native Method)
> at net.jini.security.Security.doPrivileged(Security.java:540)
> at net.jini.discovery.LookupDiscovery.beginDiscovery(LookupDiscovery.java:3100)
> at net.jini.discovery.LookupDiscovery.<init>(LookupDiscovery.java:1957)
> at net.jini.discovery.LookupDiscoveryManager.beginDiscovery(LookupDiscoveryManager.java:1493)
> at net.jini.discovery.LookupDiscoveryManager.<init>(LookupDiscoveryManager.java:936)
> I'd like to recommend a hierarchy of loggers be used in this code. I think that there would be some value in having the discovery logging support loggers with suffixes such as
> ...unicast.eth0
> ...multicast.eth0
> or
> ...eth0.multicast
> ...eth0.unicast
> to help the user be able to turn off unneed logging information. I'm not sure exactly what logger names make the most sense, but I think something with more information in the logger name would be helpful in managing the logging output more effectively.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (RIVER-13) net.jini.discovery.LookupDiscovery
logging is verbose and distracting to debugging
Posted by "Thomas Vinod Johnson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478065 ]
Thomas Vinod Johnson commented on RIVER-13:
-------------------------------------------
bq. Not setting the logger name might be considered a bug
Leaving aside the bigger question of having a deeper logger hierarchy maybe this should be filed as a separate bug. Quickly skimming through the code, it seems this issue is only present in {{LookupDiscovery}}.
> net.jini.discovery.LookupDiscovery logging is verbose and distracting to debugging
> ----------------------------------------------------------------------------------
>
> Key: RIVER-13
> URL: https://issues.apache.org/jira/browse/RIVER-13
> Project: River
> Issue Type: Improvement
> Environment: Any Machine with multiple network interfaces, some of which are not active.
> Reporter: Gregg Wonderly
>
> On my laptop computer, I have 3 different network interfaces available. Wireless, wired and bluetooth. When trying to debug certain LookupDiscovery issues, I wanted to turn logging up to the FINE level. Apon doing this, I was suddenly greeted with huge amounts of logging related to the inactive interfaces not being able to use multicast. On top of that, the logger used seems to not be setup correctly.
> Below is an extraction of the log file showing the two, recurring log entries. The HANDLED entry has a "null" logger name, which makes it difficult to know how to turn that entry on/off.
> 03/02/2007 15:05:39 [net.jini.discovery.LookupDiscovery#29] CONFIG # LookupDiscovery - multicast network interface(s): [name:lo (MS TCP Loopback interface) index: 1 addresses:
> /127.0.0.1;
> , name:eth0 (Realtek RTL8139/810x Family Fast Ethernet NIC - Packet Scheduler Miniport) index: 2 addresses:
> , name:eth1 (Bluetooth Device (Personal Area Network) #3) index: 65541 addresses:
> , name:eth2 (Broadcom 802.11b/g WLAN - Packet Scheduler Miniport) index: 1507331 addresses:
> /192.168.5.104;
> ]
> 03/02/2007 15:05:39 [null#30] HANDLED # network interface is bad or not configured for multicast: name:eth0 (Realtek RTL8139/810x Family Fast Ethernet NIC - Packet Scheduler Miniport) index: 2 addresses:
> java.net.SocketException: bad argument for IP_MULTICAST_IF2: No IP addresses bound to interface
> at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method)
> at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299)
> at java.net.MulticastSocket.setNetworkInterface(MulticastSocket.java:502)
> at net.jini.discovery.LookupDiscovery$AnnouncementListener.<init>(LookupDiscovery.java:1033)
> at net.jini.discovery.LookupDiscovery$7.run(LookupDiscovery.java:3102)
> at java.security.AccessController.doPrivileged(Native Method)
> at net.jini.security.Security$5.run(Security.java:543)
> at java.security.AccessController.doPrivileged(Native Method)
> at net.jini.security.Security.doPrivileged(Security.java:540)
> at net.jini.discovery.LookupDiscovery.beginDiscovery(LookupDiscovery.java:3100)
> at net.jini.discovery.LookupDiscovery.<init>(LookupDiscovery.java:1957)
> at net.jini.discovery.LookupDiscoveryManager.beginDiscovery(LookupDiscoveryManager.java:1493)
> at net.jini.discovery.LookupDiscoveryManager.<init>(LookupDiscoveryManager.java:936)
> I'd like to recommend a hierarchy of loggers be used in this code. I think that there would be some value in having the discovery logging support loggers with suffixes such as
> ...unicast.eth0
> ...multicast.eth0
> or
> ...eth0.multicast
> ...eth0.unicast
> to help the user be able to turn off unneed logging information. I'm not sure exactly what logger names make the most sense, but I think something with more information in the logger name would be helpful in managing the logging output more effectively.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (RIVER-13) net.jini.discovery.LookupDiscovery
logging is verbose and distracting to debugging
Posted by "Mark Brouwer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477686 ]
Mark Brouwer commented on RIVER-13:
-----------------------------------
{{LookupDiscovery}} creates various instances of {{LogRecord}} for which the logger name, source class and method is not set. Not setting the logger name might be considered a bug as that one is never filled in by the logging framework when using {{Logger.log(LogRecord)}}, the source class and method will be filled in by analysis of a generated stacktrace as soon as the source class and/or method name is requested. You must be using a formatter different than {{SimpleFormatter}} as the latter would have show the source class and method name.
Besides the ability to configure a different log level for the logger associated with the multicast failures do you envision a more general benefit of a hierarchy of loggers for {{LookupDiscovery}}. If not, another option might be to prevent from logging the same problem over and over again, i.e. keep track of the exception for a particular interface and suppress logging for the same problem in case the condition for the interface doesn't change.
> net.jini.discovery.LookupDiscovery logging is verbose and distracting to debugging
> ----------------------------------------------------------------------------------
>
> Key: RIVER-13
> URL: https://issues.apache.org/jira/browse/RIVER-13
> Project: River
> Issue Type: Improvement
> Environment: Any Machine with multiple network interfaces, some of which are not active.
> Reporter: Gregg Wonderly
>
> On my laptop computer, I have 3 different network interfaces available. Wireless, wired and bluetooth. When trying to debug certain LookupDiscovery issues, I wanted to turn logging up to the FINE level. Apon doing this, I was suddenly greeted with huge amounts of logging related to the inactive interfaces not being able to use multicast. On top of that, the logger used seems to not be setup correctly.
> Below is an extraction of the log file showing the two, recurring log entries. The HANDLED entry has a "null" logger name, which makes it difficult to know how to turn that entry on/off.
> 03/02/2007 15:05:39 [net.jini.discovery.LookupDiscovery#29] CONFIG # LookupDiscovery - multicast network interface(s): [name:lo (MS TCP Loopback interface) index: 1 addresses:
> /127.0.0.1;
> , name:eth0 (Realtek RTL8139/810x Family Fast Ethernet NIC - Packet Scheduler Miniport) index: 2 addresses:
> , name:eth1 (Bluetooth Device (Personal Area Network) #3) index: 65541 addresses:
> , name:eth2 (Broadcom 802.11b/g WLAN - Packet Scheduler Miniport) index: 1507331 addresses:
> /192.168.5.104;
> ]
> 03/02/2007 15:05:39 [null#30] HANDLED # network interface is bad or not configured for multicast: name:eth0 (Realtek RTL8139/810x Family Fast Ethernet NIC - Packet Scheduler Miniport) index: 2 addresses:
> java.net.SocketException: bad argument for IP_MULTICAST_IF2: No IP addresses bound to interface
> at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method)
> at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299)
> at java.net.MulticastSocket.setNetworkInterface(MulticastSocket.java:502)
> at net.jini.discovery.LookupDiscovery$AnnouncementListener.<init>(LookupDiscovery.java:1033)
> at net.jini.discovery.LookupDiscovery$7.run(LookupDiscovery.java:3102)
> at java.security.AccessController.doPrivileged(Native Method)
> at net.jini.security.Security$5.run(Security.java:543)
> at java.security.AccessController.doPrivileged(Native Method)
> at net.jini.security.Security.doPrivileged(Security.java:540)
> at net.jini.discovery.LookupDiscovery.beginDiscovery(LookupDiscovery.java:3100)
> at net.jini.discovery.LookupDiscovery.<init>(LookupDiscovery.java:1957)
> at net.jini.discovery.LookupDiscoveryManager.beginDiscovery(LookupDiscoveryManager.java:1493)
> at net.jini.discovery.LookupDiscoveryManager.<init>(LookupDiscoveryManager.java:936)
> I'd like to recommend a hierarchy of loggers be used in this code. I think that there would be some value in having the discovery logging support loggers with suffixes such as
> ...unicast.eth0
> ...multicast.eth0
> or
> ...eth0.multicast
> ...eth0.unicast
> to help the user be able to turn off unneed logging information. I'm not sure exactly what logger names make the most sense, but I think something with more information in the logger name would be helpful in managing the logging output more effectively.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.