Community
Participate
Working Groups
Build ID: M20080911-1700 Steps To Reproduce: 1.Deploy an application to Weblogic 9.2 compiled with debugging switched on 2.Start the Weblogic Managed server with the following JVM options -Djava.compiler=NONE -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,address=12107,suspend=n 3. From Eclipse debug configuration create new Remote Java Application 4. Select project deployed to server with connection type Standard (Socket Attach) 5. Select host name of remote machine with WLS namaged server running 6. Select port as defined in the managed server JVM startup options 12107 as in step 2 above 7. Click start 8. Eclipse shows on status line Launching XXX: (84%) 9. Eclipse reports error message window with "Failed to connect to remote VM. Connection timed out. org.eclipse.jdi.TimeoutException 10. log file contains !ENTRY org.eclipse.jdt.launching 4 113 2008-12-01 18:34:03.391 !MESSAGE Failed to connect to remote VM. Connection timed out. !STACK 0 org.eclipse.jdi.TimeoutException at org.eclipse.jdi.internal.connect.SocketTransportService.attach(SocketTransportService.java:151) at org.eclipse.jdi.internal.connect.SocketTransportImpl.attach(SocketTransportImpl.java:43) at org.eclipse.jdi.internal.connect.SocketAttachingConnectorImpl.attach(SocketAttachingConnectorImpl.java:118) at org.eclipse.jdt.internal.launching.SocketAttachConnector.connect(SocketAttachConnector.java:139) at org.eclipse.jdt.internal.launching.JavaRemoteApplicationLaunchConfigurationDelegate.launch(JavaRemoteApplicationLaunchConfigurationDelegate.java:79) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:764) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:614) at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:880) at org.eclipse.debug.internal.ui.DebugUIPlugin$8.run(DebugUIPlugin.java:1083) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) More information: This works on all of our installations prior to Ganymede. Local debugging is working fine and if we deploy the application to a WLS managed server on localhost and then connect remotely it works fine as well. It just does not work to another machine either with the IP address or DNS. I have looked at all the options and cannot find WHY remote debugging across machines in this version is broken. We are running remote WLS managed servers on Solaris with SUN JDK 150_06 and we are using the SAME JDK for the ganymede eclipse clients running on Windows 2000 I have checked the proxy settings in the windows->preferences->general->networks dialog and we have the ganymede settings set the same as our eclipse 3.3 settings and on 3.3 everything works OK We have 35 developers using Eclipse and we will be unable to go forward with this upgrade unless we are able to get the remote debugging across the network working correctly. Regards Steven McArdle
(In reply to comment #0) > I have checked the proxy settings in the > windows->preferences->general->networks dialog and we have the ganymede > settings set the same as our eclipse 3.3 settings and on 3.3 everything works > OK I tried debugging from WinXP to Linux box, which worked fine. What sort of proxy settings are you using?
To further add to this defect I have more information. If we select the Windows->Preferences->General->Network Connections dialog and select the option for Direct connection to the Internet it is possible to remote debug our servers over our LAN. This would imply that the No Proxy for: rules are being ignored somehow. I have tried to configure using the server IP addresses and the full DNS names in both the remote debug configuration and the No Proxy for: settings and they do not work with Manual proxy configuration selected. As stated previously, these settings work correctly in eclipse 3.1 - 3.3 Hope this helps to further pin point the problem. We are unable to leave this option selected permanently as the update manager and access to the internet in general is not possible due to the fact that we have a corporate proxy and firewall configured. Regards Steven McArdle
Further information: Using the name of the local machine instead of localhost in the remote debug configuration also does not work with remote debugging. Only if we use localhost as the server can we remotely debug with the Network Connections->Manual proxy configuration: selected Regards Steven McArdle
Szymon, do you know about proxy setting configurations or what might be causing this problem?
(In reply to comment #4) > Szymon, do you know about proxy setting configurations or what might be causing > this problem? > As I understand the issue is that "No proxy" doesn't work as expected. It is possible that proxy settings are affected by OS settings supported in Eclipse 3.4 and this may cause the issue. We have to verify it. I've added Pawel to the CC. He will help investigating the issue further.
I am not sure exactly what the problem is here but it would appear that when using Manual proxy configuration we are unable to remote debug applications even if we try to remote debug on a server that we have entered both the IP and DNS for in the No proxy for rules. The only exception to this is when we use remote debugging and specify localhost in the server name of the remote debug options. After further investigations today I also noticed that we cannot use Mylyn to connect to our external Bugzill and Jira servers through the proxy. With direct internet connection from my home PC I have no problem. But no settings in the proxy settings for Mylyn will allow me to connect. This may point to a problem with using proxies in general. I cannot state whether this works on previous versions of eclipse as we have never tried to configure Mylyn before 3.4 Hope this helps and if you would like me to try out any other configurations while trying to track down this problem I would be happy to do so. I don't think I mentioned it before and I don't think it's important but our corporate proxy is an IIS proxy. Regards Steven McArdle
Version: 3.3.0 Build id: I20070625-1500 Version: 3.4.1 Build id: M20080911-1700 I managed to reproduce the problem using Eclipse 3.3 as well. The cause: This is because ProxyManager which handles proxy settings in Eclipse makes them not only available through API but also through System.properties. These properties were the only way to manage proxy configuration in JSE 1.4 and are consumed by protocol handlers while opening connection. This works well for HTTP proxies since there are tree associated properties ("http.proxyHost", "http.proxyPort", "http.nonProxyHosts"). Unfortunately for SOCKS there are only two properties ("socksProxyHost", "socksProxyPort") what makes it impossible to propagate proxy bypass for socks to be JVM wide. Since JDT does not use Eclipse's IProxyService it indirectly consumes settings provided through System.properties. Steven: Do you use the same Java version with different versions of Eclipse?
Hi, I have rechecked my installations for previous eclipse version. My previous range of eclipse versions this is working in was incorrect, we previously used 3.1 -> 3.2.2 and not 3.3 as I stated so I cannot say this worked in 3.3. Here are the settings we use in the eclipse.ini for 3.2.2 -vm d:\bea\jrockit90_150_04\bin\javaw.exe -vmargs -Xms512m -Xmx768m -XX:PermSize=128M -XX:MaxPermSize=256M So we are using the BEA JRocket JVM here and not the SUN JVM Internally within eclipse for JDK5 builds we are using the SUN JDK5 JVM supplied by BEA and not JRocket and with this version ALL is working OK for Remote debugging across the network and the proxy ignore information is working as expected. For the 3.4.1 Ganymede installation the eclipse.ini file contents are 256M -startup plugins\org.eclipse.equinox.launcher_1.0.101.R34x_v20080819.jar -showsplash org.eclipse.platform --launcher.XXMaxPermSize 256m -vmargs -Dosgi.requiredJavaVersion=1.5 -Xmx512m -Xms40m -Xmx256m With a startup option of eclipse.exe -vm d:\bea\jdk150_04\bin Which is the BEA supplied SUN JVM and not the JRocket JVM we used in earlier versions. This version of the JVM is used for ALL JDK5 usage in 3.4.1 i.e. for building, debugging and starting eclipse. Hope this helps Regards Steven McArdle
Steven, thanks for the details. In the meantime try to specify the desired settings in the OS configuration and instruct Eclipse to use native settings. Does it solve your problem?
Thanks for the feed back but I don't understand what it is you are asking me to do? Are there some settings I need to set in the eclipse.ini file? Some settings in the network settings dialog? or what? If you could be more specific I will be happy to try out these settings and let you know what happens. Regards Steven McArdle
I mean you could set proxy settings in IE and select "Use system proxy settings (if available)" in Eclipse. But as I checked it doesn't work too. Darin, what about consulting IProxyService when opening remote debugging session? Would you consider such a move?
(In reply to comment #11) > Darin, what about consulting IProxyService when opening remote debugging > session? Would you consider such a move? I am not familiar with IProxyService - but how would debug use it to obtain the proxy settings for a "host:port" style address (i.e. how do I make a URI for this)?
You have to specify a schema, for remote debugging it would be SOCKS.
Created attachment 119539 [details] patch Proposed patch.
The attached patch is for the SocketAttachConnector used when remote debugging. I would like confirmation that this is the correct way to use the proxy service. Basically, the user has entered a "host:port" in the launch dialog of the address to connect to. The patch consults the service for the proxy settings to use for the user-specified address as folllows: * Creates a URI for the address (new URI("//" + host + ":" + port)) * gets the proxy settings for the URI - IProxyService.select(uri) * if proxy settings are returned, it uses the first setting returned to replace the users host/port settings before making the actual connection Is this the correct way to user the service? (Thanks).
Hi, I would like to ask if this would resolve access via the proxy in general. i.e. we also have problems with contacting our external Bugzilla and Jira repositories using the eclipse Mylyn plugin. Although we have a temporary work around for remote debugging servers on our corporate network i.e. setting the internet connection option to direct connect before starting a remote debug session this is not possible when trying to contact our external defect repositories via MyLyn... In comment #7 above it was stated that HTTP access should be unaffected. I believe this to be the case as we are able to use the update manager and generally access the web with the proxy settings configured. So could somebody confir that MyLyn also uses SOCKS and therefor this is the same problem or do we have another issue with MyLyn? Regards Steven McArdle
(In reply to comment #15) > Is this the correct way to user the service? (Thanks). The proper way to do it is to call new URI("socks://" + host + ":" + port). Since you specify proxy settings per protocol you have to provide a protocol name when querying.
(In reply to comment #16) > Hi, > > I would like to ask if this would resolve access via the proxy in general. i.e. > we also have problems with contacting our external Bugzilla and Jira > repositories using the eclipse Mylyn plugin. I don't know if the guys from Mylyn use Eclipse's IProxyService. This could be done by calling IProxyService directly or by using a higher level API that uses IProxyService internally (as I belive Eclipse Communication Framework does). > In comment #7 above it was stated that HTTP access should be unaffected. I > believe this to be the case as we are able to use the update manager and > generally access the web with the proxy settings configured. So could somebody > confir that MyLyn also uses SOCKS and therefor this is the same problem or do > we have another issue with MyLyn? AFAIK the only problem is not using proxy bypass list for accessing addresses over socks. And this is only true if the code establishing a connection doesn't use IProxyService directly (but consumes it by System.properties that IProxyService exports). If you have any other problems please provide details.
So does anybody have an idea as to a final resolution for this problem? I saw a patch mentioned earlier but it seems that discussion is still on going. If somebody does have a patched jar file that I could put into my installation and try out I would be willing to give it a good test drive. Also, it's funny you should mention the Eclipse Communication Framework because I am trying to configure this right now for our team. So far I have installed openfire onto one of our Ubuntu boxes and gone through the installation and configuration process but can't connect using the ECF wizard?? Not sure why at the moment, perhaps I just don't understand it enough yet and the documentation is almost non-existant. Anyway if I have problems with this I will raise them to the ECF team if I can only find a Bugzilla group for them! Steve
Created attachment 119620 [details] updated patch Update uses "socks:" protocol. This patch is for HEAD (3.5).
Created attachment 119624 [details] Patch for 3.4.2 maintenance stream
I created a patch that can be installed from the following update site: http://www.eclipse.org/eclipse/debug/update/ The patch for 3.4.2 is called: "Debug_Proxy_Service_Patch Feature" Please test the patch to see if this addresses the problem.
Marking as 3.4.2 candidate pending feedback.
I got this to late on Friday to check this out and we are on a long weekend here in Spain so I will test it out on Tuesday then provide my feed back for you. Just as a matter of interest will this affect all pluggins that use the eclipse proxy configuration settings such as ECF? Regards Steven McArdle
> Just as a matter of interest will this affect all pluggins that use the eclipse > proxy configuration settings such as ECF? It won't. This is just a matter of whether a particular plug-in use IProxyService. There are some directly opening connections without consulting the service (like JDT does it now). AFAIK ECF uses IProxyService so any plug-in using ECF uses the service indirectly.
Hi all, OK, I have downloaded and installed the patch and it does not work... Infact, unlike other plug-ins it will let me download and install multiple times. i.e. it does not state nothing to install. Remember, that our installed version is 3.4.1 but the patch is marked as 3.4.2, will this have an effect regarding dependencies? I still get as far as the "Launching XXX 84%" message and then after a short period I get the timeout just as before. The logged exception is as below. !ENTRY org.eclipse.jdt.launching 4 113 2008-12-09 10:24:56.434 !MESSAGE Failed to connect to remote VM. Connection timed out. !STACK 0 org.eclipse.jdi.TimeoutException at org.eclipse.jdi.internal.connect.SocketTransportService.attach(SocketTransportService.java:151) at org.eclipse.jdi.internal.connect.SocketTransportImpl.attach(SocketTransportImpl.java:43) at org.eclipse.jdi.internal.connect.SocketAttachingConnectorImpl.attach(SocketAttachingConnectorImpl.java:118) at org.eclipse.jdt.internal.launching.SocketAttachConnector.connect(SocketAttachConnector.java:139) at org.eclipse.jdt.internal.launching.JavaRemoteApplicationLaunchConfigurationDelegate.launch(JavaRemoteApplicationLaunchConfigurationDelegate.java:79) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:764) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:614) at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:880) at org.eclipse.debug.internal.ui.DebugUIPlugin$8.run(DebugUIPlugin.java:1083) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Are there some other steps I need to take to enable this patch or should it just work? Regards Steven
When you look at your plug-in details (Help > About Eclipse SDK, press "Plug-in Details"), what shows up as the version of org.eclipse.jdt.launching? First, I want to make sure the plug-in/patch was installed.
Actually, based on the stack trace, I think the patch was not installed - the line numbers in the stack trace as the same as before, but the code in SocketAttachConnector has changed...
Hi, The version of org.eclipse.jdt.launch reported by eclipse in the plug-ins is 3.4.1.v20080729_r341 So it would appear that the plug-in has not installed. Any idea how to get it installed manually as I have now tried the update manager 4 times with restarts and -clean option just to make sure. Regards Steve
Hi All, Any update on this defect? and how to install on 3.4.1? Regards Steve
We'll have to produce a new patch for you to install. Just have not had the time yet.
OK, I've created a new test patch for the 3.4.1 build. It is at the same update site (http://www.eclipse.org/eclipse/debug/update/), and is called "Debug Proxy Service Patch 341".
Still no joy, After the update manager runs I restart eclipse and check the plug-ins and features for the Eclipse IDE. The org.eclipse.jdt.launching does not show up in the plug-ins list, infact none plugins eith a feature Id of org.eclipse.jdt.* appear in this list so I looked at the feature details instead. Here is listed and entry for org.eclipse.jdt with the following values: Eclipse.org Eclipse Java Development Tools 3.4.1.r341_v20080709-0800-7o7tEAfEF_U5qyUgrb2HAp539P97 org.eclipse.jdt Select the plugin details and org.eclipse.jdt.launching is listed here: Eclipse.org Java Development Tools Launching Support 3.4.1.200812160915 org.eclipse.jdt.launching (So it would appear that the plugin is installed OK and (the Signed icon shows as broken) and the show signed info shows unsigned. The network connection properties page is configured for manual proxy and the settings are definitely correct. When I try a remote debug session I get the exact message as before: Bottom right hand side shows status Launching XXX: (84%) and then a popup window shows Problem Occured XXXXXX Failed to connect to remote VM. Connection timed out. The log file has the following exception: !ENTRY org.eclipse.jdt.launching 4 113 2008-12-18 10:53:39.903 !MESSAGE Failed to connect to remote VM. Connection timed out. !STACK 0 org.eclipse.jdi.TimeoutException at org.eclipse.jdi.internal.connect.SocketTransportService.attach(SocketTransportService.java:151) at org.eclipse.jdi.internal.connect.SocketTransportImpl.attach(SocketTransportImpl.java:43) at org.eclipse.jdi.internal.connect.SocketAttachingConnectorImpl.attach(SocketAttachingConnectorImpl.java:118) at org.eclipse.jdt.internal.launching.SocketAttachConnector.connect(SocketAttachConnector.java:151) at org.eclipse.jdt.internal.launching.JavaRemoteApplicationLaunchConfigurationDelegate.launch(JavaRemoteApplicationLaunchConfigurationDelegate.java:79) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:764) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:614) at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:880) at org.eclipse.debug.internal.ui.DebugUIPlugin$8.run(DebugUIPlugin.java:1083) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) This is different from the previous stack trace: The remote server is definitely configured to listen for connections on the right port. If I now set the Network Connection properties to System proxy configuration (if available) and try again I get the exact same sequence and exception as above. If I now set the Network Connection properties to Direct connection to the Internet I am able to remotely debug my application. So I must conclude that the patch has been installed and applied but still does not work, at least on 3.4.1. Regards Steve
Thanks for testing the update. Does your manual proxy configuration specify a port for the SOCKS proxy? My patch did not take the port into consideration (just the host name), and I wonder if that might be the problem.
After more investigation, it seems the fix to this problem is more involved: http://java.sun.com/javase/6/docs/technotes/guides/net/proxies.html Part of the problem is that debug runs on J2SE-1.4, where there is limited support for proxies. Proxy settings are controled by system properties and there is no support for a bypass list when using system properties. (In this scenario, the debugger is intended to bypass the proxy settings). To implement this properly, we may need our own utility classes or we should investigate the use of ECF for proxy related issues. Pawel suggested that it might be possible to dynamically unset/reset the system proxy settings based on the host being connected to by debug. However, this seems like a fragile solution in a multi-threaded platform. I don't see how this could have worked in any earlier release. Is it possible that you had a different proxy settings configuration?
Hi All, Sorry it's been a while since I have looked at this defect due to vacation and other pressing tasks. Here is an update from my side, 1. The SOCKS proxy setting does use a port This seems to be far more reaching than originally thought. I have just been trying to access our CVS repository from Eclipse i.e. import project from CVS and again with the Proxy Set it is unable to contact the CVS server on our local network, however with direct connection to the internet set it has no trouble connecting. We are also unable to use MyLyn as any attempt to connect to an external repository from the Task Repository results in an I/O error. As we do not have any internal bugzilla repository I cannot test to see if the works on our network. From home, with no proxy I am able to connect no problem Regards Steven McArdle
(In reply to comment #35) > After more investigation, it seems the fix to this problem is more involved: > > http://java.sun.com/javase/6/docs/technotes/guides/net/proxies.html > > Part of the problem is that debug runs on J2SE-1.4, where there is limited > support for proxies. Proxy settings are controled by system properties and > there is no support for a bypass list when using system properties. (In this > scenario, the debugger is intended to bypass the proxy settings). To implement > this properly, we may need our own utility classes or we should investigate the > use of ECF for proxy related issues. > > Pawel suggested that it might be possible to dynamically unset/reset the system > proxy settings based on the host being connected to by debug. However, this > seems like a fragile solution in a multi-threaded platform. > > I don't see how this could have worked in any earlier release. Is it possible > that you had a different proxy settings configuration? > The proxy configuration for the company has not changed in the last 2 years so it is unlikely to have anything to do with this. Doyou know if MyEclipse has the same problem with their latest release and if not why not!
> We are also unable to use MyLyn as any attempt to connect to an external > repository from the Task Repository results in an I/O error. As we do not have > any internal bugzilla repository I cannot test to see if the works on our > network. This seems to be a different case than bypassing proxy for debugging. Steven, please launch Eclipse with "-console" option to get an OSGi console. Then set up proxies and type "props" in the console. This will give you all the system properties defined in the JVM. We are interested in properties that contain "proxy" in the key. This could be helpful to narrow the root cause.
Created attachment 123369 [details] OSGI Console properties This attachment contains all the properties as reported by the OSGI Console props command.
Steven, thanks for the information. All SOCKS connections should be proxied using following entries: socksProxyHost = proxyarray.prod.oami.eu socksProxyPort = 8080 If it is not the case with MyLyn you should open a bug against their product. Like I mentioned in comment 38 debugging problem and MyLyn problem are different ones.
> Doyou know if MyEclipse has the same problem with their latest release > and if not why not! I do not know if MyEclipse has the same problem.
FYI I just spent this afternoon on this issue with our sysadmin. We use Eclipse 3.5.1 with JDK6, we use Glassfish 2 running on JDK6 as remote app server. I noted that when using "Manual" mode in network connection properties, no outgoing connection is made to the remote server from my local machine. In "Direct" mode, an outgoing connection is sent and, when we configured our proxy to allow the debugging port to go thru, it worked. If you want more infos to try to tackle the root cause of "manual" mode failing, I'm ready to help.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
