Community
Participate
Working Groups
If launching the TCF agent manually with the default port (1534) before starting up Eclipse, this agent is invisible to Eclipse and is not listed in the "Target" tab of the "Target Communication Framework" launch configuration type. Steps to reproduce: - Download and extract Eclipse 3.7.1 (SDK) - Launch it, "Help -> Install New Software..." - Enable and select the CDT update site (http://download.eclipse.org/tools/cdt/releases/indigo) - Choose "TCF -> Target Communication Framework (Incubation)" to install - Install it and restart it to commit the install operation - Close Eclipse - Build and launch the TCF agent on localhost using the default port (1534) - Launch Eclipse and use "Run -> Debug Configurations..." to open the launch config dialog - Select "Target Communication Framework", right mouse click, "New" - Switch to the target tab, uncheck both checkbox at the top of the tab and inspect the table of "Available Targets" --> The TCF agent at localhost, port 1534, launched before starting up Eclipse, is not listed (see attached screenshot) Remarks: 1. Once the "LocatorService" class is instantiate, the constructor is binding the DatagramSocket to the default port first (line 340), which succeeds if launched as described above. 2. Because of 1., the real master agents, that's the TCF agent launched externally first, discovery packets are filtered out in line 968, because "isRemote" cannot detect that the traffic is not from the Eclipse Locator Service instance (because the Eclipse Locator service instance is bound to port 1534 too). 3. If importing the TCF framework sources into an Eclipse PDE workspace and launching it as debuggee, than line 340 fails with an (expected) BindException. The Eclipse Locator service will than instantiate the DatagramSocket on a random port, become a slave. In this case, the TCF agent launched before externally is listed correctly.
Created attachment 204254 [details] Screenshot of the target tab with the launch configuration dialog
I cannot reproduce it on Windows XP. I'll try Windows 7 next.
Cannot reproduce on Windows 7. Need more details, like JRE version (I'm using 1.6.0_27), additional Eclipse plugins - if any, etc.
The Eclipse is plain 3.7.1 SDK (64bit) with only the TCF component installed as described. Nothing else is installed to this Eclipse instance. The (64bit) JRE is 1.6.0_27.
I have to correct myself about the used JRE. The default JRE used on my system is 1.7.0. If forcing Eclipse to use 1.6.0_27, the issue is gone. This appears to be a Java 7 bug.
Created attachment 204349 [details] Proposed patch to avoid address reuse With the patch attached, it does work with Java 7 as well.
Created attachment 204350 [details] Proposed patch to avoid address reuse Updated patch
Looks like a bug in Java 7, since the docs clearly say that When a DatagramSocket is created the initial setting of SO_REUSEADDR is disabled. http://download.oracle.com/javase/7/docs/api/java/net/DatagramSocket.html#setReuseAddress(boolean) Or would it matter whether the C agent has bound the socket with SO_REUSEADDR ? Have you looked for / filed a defect against Java 7 yet ?
My understanding is that Java 7 is buggy as hell at the moment. I wouldn't consider it a supported environment until it proves itself.
I have committed the patch. I have made one change before committing: before calling setReuseAddress(), the socket is now created unbound - "new DatagramSocket()" changed to "new DatagramSocket(null)". Thanks!
Fixed in master and 0.5.0: http://git.eclipse.org/c/tcf/org.eclipse.tcf.git/commit/?h=0.5.0&id=b0cbf190fc914ca3076d0a7abce3673c93c37905
