Laboratoire ICAR » Plateforme TXM

About Mac OS X:
- see comment #9 here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=330691
about a proxy bug in Eclipse under Mac OS X
- it seems there is no existent Eclipse native plug-in to manage system proxies for Mac OS ? (as org.eclipse.core.net.win32.x86_64)

LINUX, Ubuntu 13.04 and proxy (VM)

• during installation when:
  • dependencies are installed -> OK
  • installation of R packages -> OK

• during first launch of TXM when
  • java proxy configures itself: native mode -> OK
  • welcome page is shown -> OK

• during next launches of TXM when
  • updates are fetch during start-up -> OK
  • when user calls the "Check R packages" command -> OK

• Complementary tests
  • when user calls the "Check for updates" command -> OK
  • when user calls the "Add an extension" command -> OK

MAC OS X and proxy (VM)

NOTE: about proxy, the same behavior than TXM occurs in Luna, if a system proxy is set, the active provider is not set as "Manual" at first launch

NOTE found in /System/Library/Frameworks/JavaVM.framework/Home/lib/net.properties

# Whether or not the DefaultProxySelector will default to System Proxy
# settings when they do exist.
# Set it to 'true' to enable this feature and check for platform
# specific proxy settings
# Note that the system properties that do explicitely set proxies
# (like http.proxyHost) do take precedence over the system settings
# even if java.net.useSystemProxies is set to true.

# MacOSX:
# On MacOSX, setting java.net.useSystemProxies to true or false is a no-op.
# Proxy settings from System Preferences are always used and they override any
# settings specified in this file. Values from this file are only used if there
# are no proxy settings in System Preferences.
# See Release Notes for more information.

java.net.useSystemProxies=false

• during installation when:

• installation of R packages -> OK

• during first launch of TXM when
  • java proxy configures itself: native mode -> The active provider is not set as "native". It's set as "direct" and the HTTP system proxy is well defined in the "Proxy entries list" but not checked, therefore we may: 1) directly set the provider as "Manual" and check the HTTP proxy if exists 2) tell users to do the manipulation

Current state, test #1:
- manually put active provider as "Manual"
- "Add an extension" => seems OK
- "Check for updates" => null pointer exception (with no hang up)
It appears that if I set:

System.setProperty("http.proxySet", "true");

proxyService.setProxiesEnabled(true);

proxiesEnabled=true

• welcome page is shown -> OK

//TODO :
These tests has been done after having manually set the active provider to "Manual" instead of "Direct" through the preference Tools\Parameters\General\Network Connections\

• WARNING: if the proxy has not been set, at 2nd launch of TXM we still have the time out problem at splash screen when TXM tries to connect via HTTP. The duration was about 4min30 during my last tests. It means the updates fetching process is still neither UI thread independent nor cancelable through UI. It also means the problem may be present on all OS and also in the case where the connexion parameters are wrong, e.g. : having set a bad proxy or a proxy while machine is directly connected to the Internet

If we can't set ourself the active provider as "Manual" at first launch we could do :
- edit ourself the org.eclipse.core.net.prefs file (be careful, since we store the plugins in the TXM install directory, this file is duplicated in RCP user directory (.txm) AND TXM install directorie) and fill in with system proxy data :

proxyData/HTTP/hasAuth=false
proxyData/HTTP/host=proxy.domaine.fr
proxyData/HTTP/port=3128
systemProxiesEnabled=false

- create user tutorial about setting the active provider as "Manual" at first launch instead of "Direct"

• during next launches of TXM when
  • updates are fetch during start-up -> OK
  • when user calls the "Check R packages" command -> OK

• Complementary tests
  • when user calls the "Check for updates" command -> OK
  • when user calls the "Add an extension" command -> OK

WINDOWS XP 32bit and proxy

NOTE: these tests has been done without the SOCKS proxy configured in the OS.
NOTE: there is no more splash screen under Windows OS.
NOTE: the tests has been successfully passed using a .pac proxy configuration file too.

• during first launch of TXM when
  • java proxy configures itself: native mode -> OK
  • updates are fetch during start-up -> seems OK
  • welcome page is shown -> OK

• during next launches of TXM when
  • updates are fetch during start-up -> OK
  • when user calls the "Check R packages" command -> FAILED, TXM hangs up until the R time out then says "update of 'textometry' failed"

• Complementary tests
  • when user calls the "Check for updates" command -> seems OK (no updates were found) (Need to add a popup ?)
  • when user calls the "Add an extension" command -> seems OK (the windows of extensions user can install well opens)

I had a lot of reboots when manipulating the TXM UI (ex. go to Tools\Parameters at first launch), I don't know if the problem is the old machine and/or the new RCP 4.4.1 usage.

WINDOWS 7 64bit (Java 1.8, machine #2) and proxy

NOTE: there is no more splash screen under Windows OS.

• during first launch of TXM when
  • java proxy configures itself: native mode -> OK
  • updates are fetch during start-up -> seems OK but no message in log
  • welcome page is shown -> OK

• during next launches of TXM when
  • updates are fetch during start-up -> OK
  • when user calls the "Check R packages" command -> FAILED, TXM hangs up until the R time out then says "update of 'textometry' failed"

• Complementary tests
  • when user calls the "Check for updates" command -> seems OK (no updates were found) (Need to add a popup ?)
  • when user calls the "Add an extension" command -> seems OK (the windows of extensions user can install well opens)

WINDOWS 7 64bit (Java 1.7, machine #1) and proxy

NOTE: there is no more splash screen under Windows OS.

• during first launch of TXM when
  • java proxy configures itself: native mode -> OK
  • updates are fetch during start-up -> OK
  • welcome page is shown -> OK

• during next launches of TXM when
  • updates are fetch during start-up -> OK
    log:
    

    Starting update fetch
    Update levels: dev=false alpha=false beta=false
    Test if install directory rights are correct: read&write
    Ready to show Update UI
    Effectué en 3 sec.
    No update available.
    

  • when user calls the "Check R packages" command -> OK => Pop up: "Necessary packages are ready"

• Complementary tests
  • when user calls the "Check for updates" command -> OK => Console: "No update available" (Need to add a popup ?)
  • when user calls the "Add an extension" command -> seems OK => the windows of extensions user can install well opens

NOTE: after a restart needed by the adding of the "CheckTXM" extension I had a little hang up and these errors:

Starting update fetch
déc. 09, 2014 3:40:14 PM org.apache.http.impl.client.DefaultRequestDirector tryConnect
INFOS: I/O exception (java.net.SocketException) caught when connecting to the target host: Network is unreachable: connect
déc. 09, 2014 3:40:14 PM org.apache.http.impl.client.DefaultRequestDirector tryConnect
INFOS: Retrying connect
déc. 09, 2014 3:40:35 PM org.apache.http.impl.client.DefaultRequestDirector tryConnect
INFOS: I/O exception (java.net.SocketException) caught when connecting to the target host: Network is unreachable: connect
déc. 09, 2014 3:40:35 PM org.apache.http.impl.client.DefaultRequestDirector tryConnect
INFOS: Retrying connect
Update levels: dev=true alpha=true beta=true
Could not add update ALPHA repository: http://txm.textometrie.org/updates/TXMalpha
org.eclipse.core.runtime.OperationCanceledException
    at org.eclipse.equinox.internal.p2.repository.CacheManager.updateCache(CacheManager.java:370)
    at org.eclipse.equinox.internal.p2.repository.CacheManager.createCache(CacheManager.java:208)
    at org.eclipse.equinox.internal.p2.metadata.repository.SimpleMetadataRepositoryFactory.getLocalFile(SimpleMetadataRepositoryFactory.java:66)
    at org.eclipse.equinox.internal.p2.metadata.repository.SimpleMetadataRepositoryFactory.load(SimpleMetadataRepositoryFactory.java:88)
    at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.factoryLoad(MetadataRepositoryManager.java:57)
    at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:768)
    at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:668)
    at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:96)
    at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:92)
    at org.txm.rcpapplication.p2.plugins.TXMUpdateHandler.addURL(TXMUpdateHandler.java:248)
    at org.txm.rcpapplication.p2.plugins.TXMUpdateHandler.addDefaultUpdateSites(TXMUpdateHandler.java:210)
    at org.txm.rcpapplication.p2.plugins.TXMUpdateHandler.execute(TXMUpdateHandler.java:85)
    at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:294)
    at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:55)
    at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:247)
    at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:229)
    at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132)
    at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(HandlerServiceHandler.java:149)
    at org.eclipse.core.commands.Command.executeWithChecks(Command.java:499)
    at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
    at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:210)
    at org.eclipse.ui.internal.handlers.LegacyHandlerService.executeCommand(LegacyHandlerService.java:343)
    at org.eclipse.ui.internal.handlers.LegacyHandlerService.executeCommand(LegacyHandlerService.java:330)
    at org.txm.rcpapplication.ApplicationWorkbenchAdvisor$3$1.run(ApplicationWorkbenchAdvisor.java:561)
    at org.eclipse.ui.internal.UILockListener.doPendingWork(UILockListener.java:167)
    at org.eclipse.ui.internal.UISynchronizer$3.run(UISynchronizer.java:165)
    at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
    at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:136)
    at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4147)
    at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3764)
    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
    at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
    at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148)
    at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636)
    at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
    at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579)
    at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
    at org.txm.rcpapplication.Application.run(Application.java:152)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587)
    at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
    at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
    at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
Test if install directory rights are correct: read&write
Ready to show Update UI

OK, now I have a 15-20 secs hang up every time I start TXM, log:

Starting Charts Engine
Toolbox states: cqp:true R :true Espace de travail : true
Initializing the charts SWT component provider
Loading views
Prêt.
Effectué en 10 sec (10487).
Starting update fetch
Update levels: dev=true alpha=true beta=true
Test if install directory rights are correct: read&write
Ready to show Update UI
Effectué en 19 sec.

Some news:
- the time out used by the P2 updates system is set by the org.eclipse.ecf.provider.filetransfer.retrieve.connectTimeout system property (15000 ms by default)
- see https://wiki.eclipse.org/Equinox/p2/TransportDebugging for more informations
- see the number of retries properties too

P2 uses the JRE-http based transport or the Apache httpclient.
After some tests, it keeps unclear for me when Eclipse uses one or the other, it's proxy related.
It seems using for example:

 proxyService.setProxiesEnabled(true);
 proxyService.setSystemProxiesEnabled(false);

switches Eclipse to use the Apache httpclient.

Since Eclipse 4.3 the Apache httpclient was renamed httpclient4, see https://wiki.eclipse.org/Disabling_Apache_Httpclient.
I propose to force the JRE-http based transport by adding in TXM.ini:

-Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient4

it would ensure that the time out defined by:

-Dorg.eclipse.ecf.provider.filetransfer.retrieve.connectTimeout=1000

is used.
The other solution may be to specify the time out for the Appache httpclient too:
-Dorg.eclipse.ecf.provider.filetransfer.retrieve.connectTimeout=1000
-Dorg.eclipse.ecf.provider.filetransfer.httpclient4.retrieve.connectTimeout=1000

The first solution tested on Mac OS X VM + proxy seems to work fine. The second solution doesn't seem to work. Need to do more tests for the Beta 2.

Some new validations tests on two clean machines.
1) Windows 7 64bit with dynamic proxy system configuration (.pac file) => All tests OK * the provider is set to "dynamic" in RCP preferences
2) Windows 7 64bit with no network connection at all => All tests "OK"
NOTE: there's no waiting time at all when machine is not connected and not configured (unlike when a system proxy is configured in the OS but not in TXM).
The console messages may be more user friendly, actually there are only some stack trace of null or error exceptions.

NOTE: When using a captive portal, TXM welcome page request is redirected to the captive portal login page, often in HTTPS, leading to a potential security warning about the certificate (SWT Browser + Internet Explorer)

The argument:

-Dorg.eclipse.ecf.provider.filetransfer.retrieve.connectTimeout=1000

may be increased in:

-Dorg.eclipse.ecf.provider.filetransfer.retrieve.connectTimeout=2000

or:

-Dorg.eclipse.ecf.provider.filetransfer.retrieve.connectTimeout=1500

for more robustness when updating TXM with slow connections.

This issue must also be validated by executing a TXM update with proxy, without proxy, with bad connection settings, without connection at all, and more ?

Some docs about the ECF Filetransfer support: https://wiki.eclipse.org/ECF_Filetransfer_Support_for_NTLMv2_Proxies

New current state of the art of the VM args in last SVN related to the ECF filetransfer provider used by RCP/P2 update system:

-Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient4
-Dorg.eclipse.ecf.provider.filetransfer.retrieve.connectTimeout=10000
-Dorg.eclipse.ecf.provider.filetransfer.browse.connectTimeout=20000
-Dorg.eclipse.ecf.provider.filetransfer.browse.readTimeout=10000
-Dorg.eclipse.ecf.provider.filetransfer.retrieve.closeTimeout=20000
-Dorg.eclipse.ecf.provider.filetransfer.retrieve.readTimeout=20000
-Dorg.eclipse.ecf.provider.filetransfer.retrieve.retryAttempts=2
-Dsun.net.client.defaultReadTimeout=30000

The retrieve connect time out seems to have been re-raised to 10000ms which may roll back the bug encountered with proxy systems especially wrong RCP proxy configuration.
I'll try do some tests on proxy with these parameters to see if they are problematic before we build the next setup 0.7.7b2.

Test results on Windows XP with:

-Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient4
-Dorg.eclipse.ecf.provider.filetransfer.retrieve.connectTimeout=3000
-Dorg.eclipse.ecf.provider.filetransfer.retrieve.retryAttempts=2

and proxy not configured in RCP preferences.

TXM hangs up about 1-2 min after having initialized the TBX.
In think this is reasonable with these parameters that seem a good balance bewteen proxy users et non proxy users with low connection. I guess 3 seconds is sufficient for low connections.
I'm going to do some tests on Mac OS X.

The p2 update job still freezes the UI, is it possible to run it asynchronously ? (which will permit to the user to simply cancel it)

The blocking process of p2 starts near the first line of this log:

No repo - create a new artifact repo
Error while adding artifact repo: http://txm.textometrie.org/updates/TXM
org.eclipse.equinox.p2.core.ProvisionException: Communication with repository at http://txm.textometrie.org/updates/TXM failed.
    at org.eclipse.equinox.internal.p2.repository.CacheManager.createCache(CacheManager.java:151)
    at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepositoryFactory.getLocalFile(SimpleArtifactRepositoryFactory.java:65)
    at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepositoryFactory.load(SimpleArtifactRepositoryFactory.java:88)
    at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepositoryFactory.load(SimpleArtifactRepositoryFactory.java:76)
    at org.eclipse.equinox.internal.p2.artifact.repository.ArtifactRepositoryManager.factoryLoad(ArtifactRepositoryManager.java:73)
    at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:768)
    at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:668)
    at org.eclipse.equinox.internal.p2.artifact.repository.ArtifactRepositoryManager.loadRepository(ArtifactRepositoryManager.java:104)
    at org.eclipse.equinox.internal.p2.artifact.repository.ArtifactRepositoryManager.loadRepository(ArtifactRepositoryManager.java:100)
    at org.txm.rcpapplication.p2.plugins.TXMUpdateHandler.addURL(TXMUpdateHandler.java:264)
    at org.txm.rcpapplication.p2.plugins.TXMUpdateHandler.addDefaultUpdateSites(TXMUpdateHandler.java:172)
    at org.txm.rcpapplication.p2.plugins.TXMUpdateHandler.execute(TXMUpdateHandler.java:85)
    at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:294)
    at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:55)
    at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:247)
    at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:229)
    at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132)
    at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(HandlerServiceHandler.java:149)
    at org.eclipse.core.commands.Command.executeWithChecks(Command.java:499)
    at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
    at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:210)
    at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.executeItem(HandledContributionItem.java:825)
    at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.handleWidgetSelection(HandledContributionItem.java:701)
    at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.access$6(HandledContributionItem.java:685)
    at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem$4.handleEvent(HandledContributionItem.java:613)
    at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
    at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4353)
    at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1061)
    at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4172)
    at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3761)
    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
    at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
    at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
    at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148)
    at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636)
    at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
    at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579)
    at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
    at org.txm.rcpapplication.Application.run(Application.java:152)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587)
    at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
    at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
    at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
Caused by: java.net.SocketTimeoutException: connect timed out
    at java.net.TwoStacksPlainSocketImpl.socketConnect(Native Method)
    at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
    at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
    at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
    at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
    at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
    at java.net.Socket.connect(Socket.java:579)
    at sun.net.NetworkClient.doConnect(NetworkClient.java:178)
    at sun.net.www.http.HttpClient.openServer(HttpClient.java:432)
    at sun.net.www.http.HttpClient.openServer(HttpClient.java:527)
    at sun.net.www.http.HttpClient.<init>(HttpClient.java:211)
    at sun.net.www.http.HttpClient.New(HttpClient.java:308)
    at sun.net.www.http.HttpClient.New(HttpClient.java:326)
    at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:996)
    at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:932)
    at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:850)
    at org.eclipse.ecf.provider.filetransfer.browse.URLFileSystemBrowser.runRequest(URLFileSystemBrowser.java:113)
    at org.eclipse.ecf.provider.filetransfer.browse.AbstractFileSystemBrowser$DirectoryJob.run(AbstractFileSystemBrowser.java:69)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Update levels: dev=false alpha=false beta=false
Test if install directory rights are correct: read&write
Ready to show Update UI

After waiting a few when UI is freezed, and the excetpions are shown, the p2 dialog process then open in a non blocking way. I guess there is a blocking process before this log.

It seems you can define proxy settings without store them in env var for a specific command in Ubuntu using for example:

http_proxy=http://10.1.3.1:8080 apt-get update