Bug 43295 - Zeroconf always uses default port (4560)
Summary: Zeroconf always uses default port (4560)
Status: RESOLVED FIXED
Alias: None
Product: Log4j - Now in Jira
Classification: Unclassified
Component: chainsaw (show other bugs)
Version: 1.2
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: log4j-dev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-09-03 05:47 UTC by Chris Paton
Modified: 2008-06-30 15:20 UTC (History)
2 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Paton 2007-09-03 05:47:44 UTC
I've just started using Zeroconf in my log4j enabled applications and am having
problems running more than application that uses Zeroconf on the same machine. I
hope this is the appropriate place to report this problem.

I downloaded the latest release of Chainsaw (2006-03-02), and added the provided
jmdns.jar and log4j-zeroconf.jar to my apps' classpath. I then amended my log4j
configuration to use the ZeroConfSocketHubAppender. One of my apps uses
log4j-1.2.8, the other uses the version that ships with JBoss 4.0.4.GA (the Jar
is un-numbered so I'm not sure exactly).

I was able to successfully start one of my apps and receive logging events in
Chainsaw. When I came to start my second app I got:
log4j:ERROR exception setting timeout, shutting down server socket.
java.net.BindException: Address already in use
	at java.net.PlainSocketImpl.socketBind(Native Method)
	at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:359)
	at java.net.ServerSocket.bind(ServerSocket.java:319)
	at java.net.ServerSocket.<init>(ServerSocket.java:185)
	at java.net.ServerSocket.<init>(ServerSocket.java:97)
	at
org.apache.log4j.net.SocketHubAppender$ServerMonitor.run(SocketHubAppender.java:315)
	at java.lang.Thread.run(Thread.java:595)

The application popped up as expected in the Zeroconf tab in Chainsaw, but no
logging events came through, even when they appeared in my console logger. I
note that both my first and second apps had the same address:port value (port
4560) in Chainsaw's Zeroconf tab.

Having had a glance through the latest source in SVN, it seems like
ZeroConfSocketHubAppender always uses SocketHubAppender's default port (4560).
Thus when I start my second app it's unsurprising that it is unable to open a
socket on that port. I guess a fix would involve ZeroConfSocketHubAppender
retrying on a different port (e.g. +1) until it finds a free one.
Comment 1 Paul Smith 2007-09-03 16:24:38 UTC
You'll need to edit your log4j configuration file for each
ZeroconfSocketHubAppender entry and specify the 'Port' property you want to use.  

Since ZeroconfSocketHubAppender is simply a child of the standard
SocketHubAppender, all the standard parameters can be tweaked to your
requirement.  The Zeroconf bit simply broadcasts those configurations across the
network.

I don't think this is a bug.. ?
Comment 2 Chris Paton 2007-09-04 03:06:47 UTC
(In reply to comment #1)
> You'll need to edit your log4j configuration file for each
> ZeroconfSocketHubAppender entry and specify the 'Port' property you want to use.
Right you are Paul. I didn't pick up on this because, as you point out,
ZeroconfSocketHubAppender is a subclass of SocketHubAppender, which I didn't
read closely enough. I was going to suggest adding this helpful message to an
FAQ or documentation, but I suppose people may stumble across this bug on Google
anyway.

> I don't think this is a bug.. ?
Indeed, sorry for the hassle and thanks for the help.
Comment 3 Lilianne E. Blaze 2007-09-04 12:53:17 UTC
Then maybe add a "randomPort" property? It is a pain when developing X projects
to assign unique numbers to each one.
Comment 4 Paul Smith 2007-09-04 14:49:21 UTC
randomness doesn't guarantee uniqueness though..  
Comment 5 Lilianne E. Blaze 2007-09-04 14:54:22 UTC
"randomFreePort" then? Choose one above 1024, try it, choose another if
BindException, etc?
Comment 6 Chris Paton 2007-09-16 09:17:14 UTC
(In reply to comment #5)
> "randomFreePort" then? Choose one above 1024, try it, choose another if
> BindException, etc?

Having used Zeroconf/Chainsaw for another couple of weeks, this idea quite
appeals to me.

I set up each of my apps to use different ports (4561, 4562, etc.) in order to
prevent the apps from conflicting with each other. While helpful, this doesn't
work around the situation where I want to launch the same app twice. As such, a
random port property could be very useful. I'd be prepared to work on this if
people think it's useful...?
Comment 7 Paul Smith 2007-09-16 14:55:14 UTC
The more I think about it, the more I too think this is a good idea, but only in
the ZeroConfSocketHubAppender case.  That is, I don't think we should modify the
parent class to add that behavior, but allow the ZeroConf child appender class
to choose a random port. I believe passing a port value of 0 to the internal
Java Socket classes ends up choosing a random port IIRC.

I was planning on having a crack at this but I may not get to it, so if anyone
beats me to the punch feel free to attach a patch for consideration.
Comment 8 Paul Smith 2007-09-16 20:10:14 UTC
This is not as isolated as I would have liked.  I cannot find any way to do this
without exposing the ServerMonitor object embedded in SocketHubAppender as a
protected variable, or adding a new 'actualPortUsed' variable initialised by the
construction of the ServerSocket.  

Setting the 'port' property of the SocketHubAppender to 0 gives you a random
port, but the zeroconf broadcast won't see which port is actually used (it'll
simply broadcast '0' ).

The ZeroConfSocketHubAppender would need to call super.activateOptions() and
then wait a certain period of time to ensure the background ServerMonitor thread
to initialise properly before inspecting the 'actualPortUsed' variable.   Seems
a bit hacky.

This would also require a log4j change as well obviously.

The alternative is to rewrite the SocketHubAppender inside the ZeroConf project,
which isn't that appealing either.

Anyone else have any ideas?
Comment 9 Lilianne E. Blaze 2008-02-29 16:05:00 UTC
Are there any news and/or ETA on this?
Comment 10 Paul Smith 2008-03-06 21:48:11 UTC
(slow response I know).  A change to log4j is required for this to work, which is currently targetted for 1.2.16 release.

I'm amending the zeroconf package to take advantage of that; it will require you to upgrade to log4j 1.2.16 once released though, but that should easy enough.
Comment 11 Thorbjørn Ravn Andersen 2008-06-30 12:41:32 UTC
Just for the record, this is in the code in trunk, so those impatient may use that.
Comment 12 Paul Smith 2008-06-30 15:20:48 UTC
I forgot to mark this as fixed.  It has a dependency on log4j 1.2.16-SNAPSHOT, so you'll need to run that to take advantage of it.