Community
Participate
Working Groups
I get an inability to connect when using SSL. Some time after I enter the user id and password, I get a message box that says "Daemon failed to launch server on RS23 using port 0". The details showed 3 square boxes. This was debugged and commenting out this line in ClientConnection.java in method connectDaemon fixed the problem: lSocket.setSoTimeout(10000);
This is dstore specific. Dave do you think we should increase the socket timeout by default, or put the default timeout into the Preference Page you have recently added for dstore as per bug 216596 ?
The problem is that we have a fixed timeout for the daemon socket when SSL is used. In this case no timeout was specified so we shouldn't have set the timeout.
I've put a fix for this in cvs.
The fix had to be reverted for 3.0M5 due to the regression introduced as per bug 219260. It looks like the user-specified timeout value from the Preferences : Remote Systems : DStore page is not honored. Kevin Doyle suggests: If you want to try something you can make this change: DStoreConnectorServer line 646: launchStatus = launchServer(clientConnection, info, daemonPort, monitor); change it to: launchStatus = launchServer(clientConnection, info, daemonPort, monitor, timeout); That should make it use the user preference page timeout. But note that a default timeout of 30000 would mean that a user not connecting via SSL would need to wait 30 seconds before the SSL attempt times out and the non-SSL connection is made. So if that change is made, the default timeout should be changed to a lower value.
Also note that the committed change to ClientConnection v1.16 -> v1.17 introduced a breaking API change, since ClientConnection is a public class in a public package, and method public ConnectionStatus connectDaemon(int daemonPort) { was changed to public ConnectionStatus connectDaemon(int daemonPort, int timeout)
I've fixed this to use the user preference and changed the default from 30000 to 10000.
But this still means that a user who's not using SSL needs to wait 10 seconds before he can connect to the server, right? This seems like a regression to me. It was much faster before the change.
I could change the defect socket timeout to something lower if it helps. I would encourage SSL to be preferable to non-SSL due to security issues. What would you suggest?
(In reply to comment #6) > I've fixed this to use the user preference and changed the default from 30000 > to 10000. I wanted to test/verify the fix, but when I go to the Prefs Page I still see 30000. When I press "Restore Defaults" it still shows 30000. Where did you change that default?
(In reply to comment #9) > (In reply to comment #6) > > I've fixed this to use the user preference and changed the default from 30000 > > to 10000. > I wanted to test/verify the fix, but when I go to the Prefs Page I still see > 30000. When I press "Restore Defaults" it still shows 30000. Where did you > change that default? I changed the line to here in IUniversalDStoreConstants: public static final int DEFAULT_PREF_SOCKET_TIMEOUT = 100000; The code in the preference page to apply the defaults is this: protected void performDefaults() { super.performDefaults(); int timeout = IUniversalDStoreConstants.DEFAULT_PREF_SOCKET_TIMEOUT; _connectionTimeout.setText(""+timeout); //$NON-NLS-1$ ... } It works for me.
Ok, the default setting works correctly now. But still, I'm not happy with the user experience. Even with 10 sec timeout, connecting a remote system with a dstore daemon that does NOT have SSL is unbearably slow. I can see following two possibilities to improve the situation: (a) Change the timeout to an even smaller value e.g. 1 second only. If user cannot connect due to timeout, have error message tell him how to increase the timeout. (b) Add API to the dstore daemon to query whether SSL is available or not. Connect without SSL first. If query returns that SSL is available, make another connection but this time with SSL. I'm more in favor of (b) because in case a server is really far away and user needs to increase the timeout to e.g. 20 seconds for whatever reason, and he does not have SSL, he would unnecessarily have to wait 20 seconds every time. With option (b), non-SSL users are as fast as they can possibly be; SSL users have to suffer one extra roundtrip which should be OK because it happens at maximum possible speed. If option (b) is selected, a useful default timeout might be 15 or 20 seconds.
PS in some environments, security guidelines might require connecting with SSL. I think we should have a "Force connect with SSL" checkbox in the Preference, preferrably on the SSL Preference Page. Also, the SSL Preference Page should have a "Show Warning Dialog when not using SSL" checkbox connected to the "Do not Show Again" checkbox on the corresponding warning dialog.
I was always under the understanding that the client has no control over whether SSL is used for the connection and that it is set by the server administrator in the ssl.properties file.
Chris, with the latest RSE drops are you able to reproduce this?
What is the status of this? Dave, can we close it?
I'm going to close this as works for me since I don't think this is an issue with our current drivers and I haven't heard any feedback for a while.
