Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 359350

Summary: [Locator] Locator service fails to list local host (master) TCF agent
Product: [Tools] TCF Reporter: Uwe Stieber <uwe.st>
Component: CoreAssignee: Project Inbox <tcf.core-inbox>
Status: RESOLVED FIXED QA Contact: Eugene Tarassov <eugene>
Severity: normal    
Priority: P3 CC: cdtdoug, mober.at+eclipse
Version: unspecified   
Target Milestone: 0.5.0   
Hardware: PC   
OS: Windows 7   
Whiteboard:
Attachments:
Description Flags
Screenshot of the target tab with the launch configuration dialog
none
Proposed patch to avoid address reuse
none
Proposed patch to avoid address reuse eugene: iplog-

Description Uwe Stieber CLA 2011-09-29 03:16:35 EDT 
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.
Comment 1 Uwe Stieber CLA 2011-09-29 03:22:52 EDT 
Created attachment 204254 [details]
Screenshot of the target tab with the launch configuration dialog
Comment 2 Eugene Tarassov CLA 2011-09-29 13:10:00 EDT 
I cannot reproduce it on Windows XP.
I'll try Windows 7 next.
Comment 3 Eugene Tarassov CLA 2011-09-29 13:58:01 EDT 
Cannot reproduce on Windows 7.

Need more details, like JRE version (I'm using 1.6.0_27), additional Eclipse plugins - if any, etc.
Comment 4 Uwe Stieber CLA 2011-09-29 14:02:29 EDT 
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.
Comment 5 Uwe Stieber CLA 2011-09-30 03:49:50 EDT 
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.
Comment 6 Uwe Stieber CLA 2011-09-30 03:51:19 EDT 
Created attachment 204349 [details]
Proposed patch to avoid address reuse

With the patch attached, it does work with Java 7 as well.
Comment 7 Uwe Stieber CLA 2011-09-30 03:56:15 EDT 
Created attachment 204350 [details]
Proposed patch to avoid address reuse

Updated patch
Comment 8 Martin Oberhuber CLA 2011-09-30 05:02:18 EDT 
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 ?
Comment 9 Doug Schaefer CLA 2011-09-30 10:23:35 EDT 
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.
Comment 10 Eugene Tarassov CLA 2011-09-30 13:15:14 EDT 
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!