Community
Participate
Working Groups
Build ID: M20080819-0600 I am using RSE on Windows XP to connect to a dstore daemon on AIX 5.1. Here are modified newsgroup postings and additional information on this topic I was previously connecting to a running server and was being prompted once for my user ID and password when I connected (as expected). We just got the dstore daemon running and now when I connect to the daemon, I am almost always prompted a second time for my user name and password. The second prompt indicates the password is optional and I succesfully connect whether I enter the password or not. Why would I be prompted a second time for my user ID and password when connecting to the dstore daemon and why would the password be optional the second time? I looked in the user's guide and couldn't find info about it. Now I am also regularly seeing a failure to connect. The error indicates "RSEG1242" and says "Daemon failed to launch server on <my machine> using port 0". The failure message comes after entering the user ID/password the first time. Sometimes the connect failure is a real failure and sometimes I get prompted for my user ID/password after dismissing the message and the connection seems fine. We start the daemon with the following command: cd /opt/rseserver; /usr/bin/perl ./daemon.pl 4075 12200-12209 We also enable SSL using the instructions in the RSE User's guide. Could we have set up something wrong causing the connection error and multiple user ID/password prompts? Also wanted to reiterate that when I was connecting to a running server, everything worked as expected and the strangeness started once we started connecting to the daemon. I have tried connecting from another machine with another user ID several times and those tries resulted in the multiple user ID/password prompting but no connect failure messages. I have noticed that some of the java processes on the AIX machine linger around for a while after disconnecting or after a connect failure. They go away after a minute or two. Didn't know if that might be important. The java -version output on the AIX machine is below java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2) Classic VM (build 1.4.2, J2RE 1.4.2 IBM AIX build ca142ifx-20070716 (ifix:122573 SR7 + 121135) (JIT enabled: jitc)) If there are more configuration questions or help I can provide, let me know. I've been trying to determine if I have some sort of configuration issue.
A couple questions: When you run the daemon are you able to see any messages on the remote machine's console after your attempts to connect to it? In the RSE how do you connect? Implicitly via expansion of a filter? Explicitly via a connect popup menu action on a subsystem or the host?
I have looked at the output to the console and don't see anything unusual when I am double prompted for user ID/password. Here's what I see: handshake completed launched new server on 12200 <output from by .profile> SSL Settings [daemon keystore: /opt/rseserver/.keystore] [daemon keystore pw: d98kMn50sV] [server keystore: /opt/rseserver/.keystore] [server keystore pw: d98kMn50sV] All of this output happens before the second prompt. This happens when explicitly connecting via pop up on the host. I just noticed that after I am connected, the Connect is not grayed out in the pop up and if I select Connect again, I see the user ID/password prompt with the optional password. I tried a few implicit connections by expanding folders and in these cases, I was only prompted once. Although I was seeing the connect failure message this morning, I haven't been able to make that happen again.
Also, I had our AIX level wrong. We are on AIX 5.3
OK, I just saw the failure message again. I see it with both implicit and explicit connections. On the server side, the only output is "handshake failed". It's weird because it seems like it fails a few times when you try connecting, then if you wait a few minutes or so and try again, it works.
If you connect by selecting the file subsystem (i.e. "Files"), right-mouse-click "Connect..." do you see both prompts? If the password has been saved (i.e. you checked off the checkbox) do you get the duplicate prompts?
OK, I tried Files -> Connect. The first 2 tries resulted in the connect failure message and no connection. I then waited several minutes. The 3rd try resulted in success with only one user ID/password prompt. I retried Connect from the Host and got 2 prompts. I tried Connect from the Host and checked the Save password and there was only one prompt. Retried Connect from Host after the try when I checked the password box and there were no prompts.
Some info on the connection failed message. I noticed some processes hanging around that correspond to the times when I got connection failed messages. Seems the daemon is sometimes not finding the correct user ID and that is causing the failure. root 319604 307570 0 18:31:57 - 0:00 perl /opt/rseserver//auth.pl null /opt/rseserver/ 1 2200-12209 120000 1220135517194 /usr/java5_64/jre root 340104 307570 0 13:38:58 - 0:00 perl /opt/rseserver//auth.pl null /opt/rseserver/ 1 2200-12209 120000 1220117938611 /usr/java5_64/jre root 405514 307570 0 18:31:00 - 0:00 perl /opt/rseserver//auth.pl null /opt/rseserver/ 1 2200-12209 120000 1220135460783 /usr/java5_64/jre root 475236 307570 0 18:31:21 - 0:00 perl /opt/rseserver//auth.pl null /opt/rseserver/ 1 2200-12209 120000 1220135481886 /usr/java5_64/jre The connect failure has happened when explicitly and implicitly connecting.
Also, I forgot to mention that we updated our PATH to use Java 1.5 when starting the dstore daemon. Thanks.
(In reply to comment #7) > Some info on the connection failed message. I noticed some processes hanging > around that correspond to the times when I got connection failed messages. > Seems the daemon is sometimes not finding the correct user ID and that is > causing the failure. > > root 319604 307570 0 18:31:57 - 0:00 perl /opt/rseserver//auth.pl > null /opt/rseserver/ 1 > 2200-12209 120000 1220135517194 /usr/java5_64/jre > root 340104 307570 0 13:38:58 - 0:00 perl /opt/rseserver//auth.pl > null /opt/rseserver/ 1 > 2200-12209 120000 1220117938611 /usr/java5_64/jre > root 405514 307570 0 18:31:00 - 0:00 perl /opt/rseserver//auth.pl > null /opt/rseserver/ 1 > 2200-12209 120000 1220135460783 /usr/java5_64/jre > root 475236 307570 0 18:31:21 - 0:00 perl /opt/rseserver//auth.pl > null /opt/rseserver/ 1 > 2200-12209 120000 1220135481886 /usr/java5_64/jre > > The connect failure has happened when explicitly and implicitly connecting. > Hmm... the first argument to the auth.pl script is supposed to be the user id. The usage is: auth.pl USER, PATH, PORT, TIMEOUT, TICKET In this case USER is null for some reason. The daemon (i.e. ServerLauncher) reads the user, password and port from the socket when the client requests a new server but it seems that in this case it's coming back as null. I'm not sure why it would work sometimes and others not. Another interesting thing I notice is that 1 is specified as the port to launch the server on. Could you try changing the subsystem port from 1 to 0?
The subsystem is set at "0 (Default or first available)". I don't know why it would be using "1". Also, when we start the daemon we indicate the following server port range "12200-12209"
(In reply to comment #10) > The subsystem is set at "0 (Default or first available)". I don't know why it > would be using "1". Also, when we start the daemon we indicate the following > server port range "12200-12209" > Does it make any difference if you dont' specify a port range when starting the daemon?
Haven't tried that. Would need to work with my admin and get back to you. However, I checked processes again because I just failed several times before successfully connecting and these have valid port ranges. The processes I posted previously were from a different machine so I will look at that machine again to make sure it was set up properly. /bin/ksh /home/apps/denises/swacstuff> checkdaemon root 278626 492432 0 Aug 31 - 0:00 perl /opt/rseserver//auth.pl null /opt/rseserver/ 12200-12209 120000 1220192177411 /usr/java5_64/jre root 892988 492432 0 14:48:21 - 0:00 perl /opt/rseserver//auth.pl null /opt/rseserver/ 12200-12209 120000 1220467700918 /usr/java5_64/jre root 1081430 492432 0 14:48:21 - 0:00 perl /opt/rseserver//auth.pl null /opt/rseserver/ 12200-12209 120000 1220467700054 /usr/java5_64/jre root 348600 492432 0 15:03:05 - 0:00 perl /opt/rseserver//auth.pl denises /opt/rseserver/ 12200-12209 120000 1220468585717 /usr/java5_64/jre root 901510 492432 0 Aug 31 - 0:00 perl /opt/rseserver//auth.pl null /opt/rseserver/ 12200-12209 120000 1220192192920 /usr/java5_64/jre root 1118476 492432 0 14:52:23 - 0:00 perl /opt/rseserver//auth.pl null /opt/rseserver/ 12200-12209 120000 1220467943034 /usr/java5_64/jre root 316136 492432 0 14:56:38 - 0:00 perl /opt/rseserver//auth.pl null /opt/rseserver/ 12200-12209 120000 1220468198235 /usr/java5_64/jre root 340672 492432 0 Aug 30 - 0:00 perl /opt/rseserver//auth.pl null /opt/rseserver/ 12200-12209 120000 1220110333522 /usr/java5_64/jre root 1008196 492432 0 Aug 30 - 0:00 perl /opt/rseserver//auth.pl null /opt/rseserver/ 12200-12209 120000 1220110393498 /usr/java5_64/jre root 492432 860592 0 Aug 29 - 0:41 java -DA_PLUGIN_PATH=/opt/rseserver/ -DDSTORE_TRACING_ON=false org.eclipse.dstore.core.server.ServerLauncher 4075 12200-12209 denises 549654 348600 5 15:03:05 - 0:06 /usr/java5_64/jre/bin/java -cp /opt/rseserver:/opt/rseserver/dstore_extra_server.jar:/opt/rseserver/dstore_core.jar:/opt/rseserver/dstore_miners.jar:/opt/rseserver/clientserver.jar -DA_PLUGIN_PATH=/opt/rseserver/ -DDSTORE_SPIRIT_ON=true org.eclipse.dstore.core.server.Server 12200-12209 120000 1220468585717 denises 983850 532992 0 15:03:39 - 0:00 grep /rseserver root 1082296 492432 0 Aug 31 - 0:00 perl /opt/rseserver//auth.pl null /opt/rseserver/ 12200-12209 120000 1220192187865 /usr/java5_64/jre denises 541130 532992 0 15:03:40 - 0:00 grep daemon.pl root 860592 238172 0 Aug 29 - 0:00 /usr/bin/perl ./daemon.pl 4075 12200-12209 /home/apps/denises/swacstuff>
I just looked at the first set of processes I indicated below again and realized there was a carriage return inserted in the line when I cut and pasted. "1" isn't being passed in as the port, the line is split between the "1" and the "2" of "12200". Sorry for the confusion. I can still try not specifying a port range with my admin if you like and think it might make a difference but in production we have to specify the port range. Thanks.
Created attachment 111618 [details] patch to not launch a server when unable to read daemon socket I've noticed a problem here that explains why you've got attempts to connect when there is a null user id. The problem is that when the client tries to connnect to the server with SSL, but the server isn't in SSL, we end up calling auth.pl with bad params. Instead we should not even attempt it and wait for the non-secure connection attempt that follows. With this patch, does your situation improve at all?
(In reply to comment #13) > I just looked at the first set of processes I indicated below again and > realized there was a carriage return inserted in the line when I cut and > pasted. "1" isn't being passed in as the port, the line is split between the > "1" and the "2" of "12200". Sorry for the confusion. I can still try not > specifying a port range with my admin if you like and think it might make a > difference but in production we have to specify the port range. Thanks. > Yeah, I guessed that was the case. I'll provide an updated dstore_core.jar here so that you can try out my patch.
Created attachment 111620 [details] updated dstore_core.jar with patch to try on server
I will try to check this on Thursday. I didn't quite understand this point: "The problem is that when the client tries to connnect to the server with SSL, but the server isn't in SSL, we end up calling auth.pl with bad params." Our server is set up to use SSL per instructions in the RSE user's guide. Would that mean the fix you provided may not make a difference?
(In reply to comment #17) > I will try to check this on Thursday. I didn't quite understand this point: > > "The problem is that when the client tries to connnect to the server with SSL, > but the server isn't in SSL, we end up calling auth.pl with bad params." > > Our server is set up to use SSL per instructions in the RSE user's guide. > Would that mean the fix you provided may not make a difference? Hmm... I would have expected those auth.pl processes are the remains of attempts that were made when you hadn't setup SSL. Make sure after updating the server jar that you restart the daemon.
Note that the fix attached here has been released into http://download.eclipse.org/dsdp/tm/downloads/drops/M-3.0.1RC1-200809041436/ so you can try the binary build from there.
With new dstore_core.jar - Explicit connect from Files subsystem resulted in connection failure. However, there were no lingering processes on AIX machine this time. I monitored processes while trying to connect and this time the user ID was resolved properly. denises 282754 152374 0 09:19:26 pts/144 0:00 grep /rseserver root 1413476 365492 2 09:19:25 - 0:00 perl /opt/rseserver//auth.pl denises /opt/rseserver/ 12200-12209 120000 1220620764819 /usr/java5_64/jre root 365492 606938 3 17:13:21 - 0:12 java -DA_PLUGIN_PATH=/opt/rseserver/ -DDSTORE_TRACING_ON=false org.eclipse.dstore.core.server.ServerLauncher 4075 12200-12209 denises 865068 1413476 10 09:19:26 - 0:00 -ksh -c /usr/java5_64/jre/bin/java -cp /opt/rseserver:/opt/rseserver/dstore_extra_server.jar:/opt/rseserver/dstore_core.jar:/opt/rseserver/dstore_miners.jar:/opt/rseserver/clientserver.jar -DA_PLUGIN_PATH=/opt/rseserver/ -DDSTORE_SPIRIT_ON=true org.eclipse.dstore.core.server.Server 12200-12209 120000 1220620764819 denises 282756 152374 0 09:19:27 pts/144 0:00 grep daemon.pl root 606938 507946 0 17:13:21 - 0:00 /usr/bin/perl ./daemon.pl 4075 12200-12209 But the connection still failed. This time there were details in the RSEG1242 error dialog and those were "unknown problem connecting to server". Implicit connection by expanding My Home - same error as described for explicit connection above. Explicit connection from host - same error as described above plus the additional user ID/password prompt. I actually have not yet been able to successfully connect to my remote machine with the new JAR.
Removed at user request
>Removed at user request Are you still able to connect to the running server as before? Are you able to connect with the daemon when SSL is disabled?
OK, connecting to a running server still works with the new JAR file. I did note that an explicit connection from the host to the running server resulted in two password prompts so it would seem that behavior is the same whether using daemon or running server. I had initially thought the behavior was different but now that I've tested this so many times, I can't be sure why I thought that. I am no longer considering the multiple prompting an issue, as it seems it is just the way it is when you connect by pop up from the host. Next I tried disabling SSL for the daemon and using the new JAR file. I still can't connect. The failure is the same a previously described. The failure now seems to be permanent though instead of intermittent. I have not yet been able to connect to the remote system.
(In reply to comment #23) > OK, connecting to a running server still works with the new JAR file. I did > note that an explicit connection from the host to the running server resulted > in two password prompts so it would seem that behavior is the same whether > using daemon or running server. I had initially thought the behavior was > different but now that I've tested this so many times, I can't be sure why I > thought that. I am no longer considering the multiple prompting an issue, as > it seems it is just the way it is when you connect by pop up from the host. Regarding the connection from host, I think what may be happening is there are more the one connector service involved with the subsystems your connection has. For example, if you have a terminal subsystem, it will independently prompt for password. If you just connect the file subsystem, then only it and other subsystems that use it's connector service will connect - so I'd expect the terminal subsystem won't prompt in that case.
What you are saying about the second prompt makes sense. Thanks. Is there anything else I should try with the updated JAR file? If not, I am going to have our admin go back to the original JAR file as I have not been able to connect successfully at all since we put the updated JAR file in place. The change has made our situation worse and not better. Is there anything else I should try with the original JAR file to determine why the connection failure is happening? Thanks.
(In reply to comment #25) > What you are saying about the second prompt makes sense. Thanks. > > Is there anything else I should try with the updated JAR file? If not, I am > going to have our admin go back to the original JAR file as I have not been > able to connect successfully at all since we put the updated JAR file in place. > The change has made our situation worse and not better. > > Is there anything else I should try with the original JAR file to determine why > the connection failure is happening? > > Thanks. > Did you try the latest build of the jar from the RSE m-builds? http://www.eclipse.org/downloads/download.php?file=/dsdp/tm/downloads/drops/M20080902-0600/rseserver-M20080902-0600-unix.tar
Should I be trying M20080902-0600 or 3.0.1RC1? The former won't have your fix and that latter will, correct? I tried updating to M20080902-0600 on the client and server side, without enabling SSL and all connections were successful (implicit, explicit host and subsystem). I'm awaiting my admin to reenable SSL to see if everything still is successful. Should I then try 3.0.1RC1?
(In reply to comment #27) > Should I be trying M20080902-0600 or 3.0.1RC1? The former won't have your fix > and that latter will, correct? > > I tried updating to M20080902-0600 on the client and server side, without > enabling SSL and all connections were successful (implicit, explicit host and > subsystem). I'm awaiting my admin to reenable SSL to see if everything still > is successful. > > Should I then try 3.0.1RC1? > Yes, please try this with 3.0.1 RC1.
The connection failures return with M20080902-0600 when we enable SSL. Implicit and explicit from host and subsystem all fail. Will now try with 3.0.1RC1.
(In reply to comment #29) > The connection failures return with M20080902-0600 when we enable SSL. > Implicit and explicit from host and subsystem all fail. > > Will now try with 3.0.1RC1. > I'm not sure whether or not this will help but could you try the following. In the preference pages under Remote Systems, goto the SSL preference page. Remote all the listed certificates. Then try connecting again.
I did not get the chance to try clearing the certificates with M20080902-0600 to see if it helps. Here are the results from 3.0.1RC1 - SSL not enabled - All connections are successful. SSL enabled - All connections failed. Before getting the connection failure message, the "this connection NOT secured with SSL" message pops up. Don't know why it would pop up since it did indicate receiving a certificate. I did removed certificates before each attempt to connect. Daemon indicated "handshake completed" for each attempt but each connection failed.
OK, for the fun of it I tried connecting to a running server with SSL enabled. I had not tried previously tried to enable SSL without using the daemon. Anyway, if I enable SSL and connect to the running server, all connections fail (implicit, explicit host and subsystem) and the server outputs "handshake failed". So it would seem the problem may lie within the server trying to work out SSL with the client.
(In reply to comment #32) > OK, for the fun of it I tried connecting to a running server with SSL enabled. > I had not tried previously tried to enable SSL without using the daemon. > Anyway, if I enable SSL and connect to the running server, all connections fail > (implicit, explicit host and subsystem) and the server outputs "handshake > failed". So it would seem the problem may lie within the server trying to work > out SSL with the client. > I'm thinking that you were able to connect fine to the daemon, but there was a problem when connecting to the server with SSL. In the ssl.properties file are you using a different keystore file for the server than the one for the daemon? In my configurations I usually use the same for both (i.e. I leave the server fields commented out).
We leave the server fields commented out. I did try explicitly putting the same file and password from the daemon fields into the server fields to see if that made a difference and it did not.
(In reply to comment #34) > We leave the server fields commented out. I did try explicitly putting the > same file and password from the daemon fields into the server fields to see if > that made a difference and it did not. > Is the path to keystore file fully qualified in the ssl.properties file?
Also, do regular users have read access to the ssl.properties file?
Yes, the path is fully qualified. Yes, all users have read access to the ssl.properties file.
Is the java version that your user id uses (i.e. the one in your path) the same as the one that root uses?
No, root uses Java 5 and my user ID defaults to Java 1.4.2. I updated my .profile to add the same Java path root uses to my own path and tried to connect again. I still got the same failures (including the pop up indicating it was not secured using SSL). Here is the output from java -version java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pap64devifx-20071025 (SR6b)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 AIX ppc64-64 j9vmap6423-20071007 (JIT enabled) J9VM - 20071004_14218_BHdSMr JIT - 20070820_1846ifx1_r8 GC - 200708_10) JCL - 20071025
(In reply to comment #39) > No, root uses Java 5 and my user ID defaults to Java 1.4.2. > > I updated my .profile to add the same Java path root uses to my own path and > tried to connect again. I still got the same failures (including the pop up > indicating it was not secured using SSL). > > Here is the output from java -version > > java version "1.5.0" > Java(TM) 2 Runtime Environment, Standard Edition (build pap64devifx-20071025 > (SR6b)) > IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 AIX ppc64-64 j9vmap6423-20071007 > (JIT enabled) > J9VM - 20071004_14218_BHdSMr > JIT - 20070820_1846ifx1_r8 > GC - 200708_10) > JCL - 20071025 > Hmm..I'm running out of ideas and I'm not able to reproduce this. Have you tried this on another system (i.e. a linux box)? Have you tried creating a new keystore and using it instead of the one you have now?
I don't have access to a linux system that I can test with. We created a new keystore and the first few attempts to connect failed. I honestly can't say whether I deleted certificates but I'm fairly certain that I did during the failures. But then I deleted the connection completely from the remote systems view and recreated it. I then deleted all certificates. Now connections with SSL enabled are working. I've tried implicit and explicit connections and all seem to work. I'd like to give this another day or two to see if the failures are really gone before assuming that there is no longer an issue. I plan to update a couple other AIX machines to make sure they work as well. I do have a question though. Does it matter whether the AIX machines I connect to have the same or different keystores? We were creating the same keystore on each machine we connect to. Thanks.
(In reply to comment #41) > Does it matter whether the AIX machines I > connect to have the same or different keystores? > I don't think it should matter whether the keystores are the same or different.
The only connection now that doesn't work with SSL enabled is one to a machine where I do not have a home directory (the machine sticks me in a guest directory because my home directory is not crossmounted). Is there a limitation that you can't connect with SSL enabled to a machine you don't have a home directory on? If I disable SSL, I can connect but the server spits out an IO exception and complains it can't create a file in my home directory path (.eclipse/RSE/denises/rsecomm.log). Thanks.
(In reply to comment #43) > The only connection now that doesn't work with SSL enabled is one to a machine > where I do not have a home directory (the machine sticks me in a guest > directory because my home directory is not crossmounted). Is there a > limitation that you can't connect with SSL enabled to a machine you don't have > a home directory on? If I disable SSL, I can connect but the server spits out > an IO exception and complains it can't create a file in my home directory path > (.eclipse/RSE/denises/rsecomm.log). Thanks. > I wasn't aware that there was an SSL-specific problem when you don't have a home directory. As for the .eclipse/RSE/... thing, the server tries to put it's logs in relative to your home directory.
My admin crossmounted my home directory to the last machine and now those connections are working as well. So, for now I don't have any connection issues anymore. However, it looks like there is a limitation in the code somewhere for SSL enabled connections when there is no user home directory.
I guess it was too good to be true. I spent about an hour again struggling with connection failures to all 3 machines I'm testing this with. I had reinstalled my Windows Eclipse baseline (with 3.0.1RC1) and the failures started again. After trying and retrying, deleting certificates and even workspace metadata, I was still getting failures. Then, all of sudden, I was able to connect to one machine. A few tries later with the other 2 and I was able to successfully connect to them as well. It seems like there might be some conditional code or timeout or something like that when the client and server are trying to exchange data to use SSL which then causes the failure. I could try looking at the code as well if you want to point me in the right direction. Although, I'm still a Java novice. I enabled more logging and see a bunch of messages like below in both failure and successful cases. Don't know if that means much. !ENTRY org.eclipse.rse.ui 1 0 2008-09-12 12:34:39.382 !MESSAGE in SubSystemConfiguration.getSubSytems(conn, force) - returning empty array !ENTRY org.eclipse.rse.ui 1 0 2008-09-12 12:34:39.382 !MESSAGE in SubSystemConfiguration.getSubSytems(conn, force) - returning empty array
(In reply to comment #46) > I guess it was too good to be true. I spent about an hour again struggling > with connection failures to all 3 machines I'm testing this with. I had > reinstalled my Windows Eclipse baseline (with 3.0.1RC1) and the failures > started again. After trying and retrying, deleting certificates and even > workspace metadata, I was still getting failures. Then, all of sudden, I was > able to connect to one machine. A few tries later with the other 2 and I was > able to successfully connect to them as well. It seems like there might be > some conditional code or timeout or something like that when the client and > server are trying to exchange data to use SSL which then causes the failure. I What you may want to try is increasing the timeout values that show on the Remote Systems->DataStore preference page.
I am trying the suggestion to increase timeout values. So far it doesn't appear to make much difference. The failures are still intermittent. What exactly does each value control? Connection Timeout Socket Read Timeout Keepalive Response Timeout It would seem from the names that only the Connection Timeout may be involved in the code path during connection with SSL enabled. Is that the case?
OK, I increased the Connection Timeout from 5000 ms to 20000 ms. Using the new value, I have been able to successfully connect every time. I also had another user try with the updated timeout value and all connections have been successful. So it would seem that enabling SSL in our environment added enough processing to the connection code path that the default timeout was sometimes sufficient but most of the time insufficient. Is there a way I can increase this timeout value before distributing Eclipse with RSE to my users? I'd hate to have to tell every user to manually change this value after the install. Thanks.
See "plugin customizations" on http://dsdp.eclipse.org/help/latest/topic/org.eclipse.rse.doc.isv/reference/misc/runtime-options.html You basically create a plugin_customization.ini file and register that in your product's primary feature ("products" extension point). Preferences from that ini file are autmatically set when the product is launched the first time. You can tune *all* Eclipse Preferences by that method.
The link under "Plugin Customizations" ("Customizing a product") from the page you provide a link for doesn't work for me. Is it a bad link?
I found the section that the link was supposed to bring up. I also found the http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.rse.doc.isv/reference/api/constant-values.html page when looking for the name of the preference for connection timeout. Is the name of the preference RESID_PREF_SOCKET_TIMEOUT? I didn't see anything with "connection_timeout" in its name. Thanks.
(In reply to comment #52) > I found the section that the link was supposed to bring up. I also found the > http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.rse.doc.isv/reference/api/constant-values.html > page when looking for the name of the preference for connection timeout. Is > the name of the preference RESID_PREF_SOCKET_TIMEOUT? I didn't see anything > with "connection_timeout" in its name. Thanks. > Yes, RESID_PREF_SOCKET_TIMEOUT is the connection timeout.
So, this can be marked fixed?
Yes you can mark as fixed. You could consider raising your default value some if you think failures are likely to happen to other users at the current setting.
I have a couple questions about the preference. I haven't tried changing preferences like this before. The value of this preference is a string "org.eclipse.rse.connectorservice.dstore.ui.preferences.sockettimeout". I guess this means I can't just change it to "20000". I looked in the RSE code for a constant or object with this name and couldn't find it. How does this string resolve to the value 5000? Also, you mentioned "You basically create a plugin_customization.ini file and register that in your product's primary feature ("products" extension point).". I confused myself trying to figure out how to do this using the Ganymede documentation so would you mind giving me a pointer on how to "register that in your product's primary feature"? Thanks!
I checked this just quickly: (1) org.eclipse.rse.connectorservice.dstore/Activator.java -- initializeDefaultPreferences() is called from the Activator.start() method. Because of that, I'm afraid that the plugin_customization.ini method won't work in this case. This is bug 245918 which is unfortunately *not* fixed in TM 3.0.1 ! (2) In case it would work, just look at Eclipse itself: plugin org.eclipse.sdk includes a plugin_customization.ini file. That bundle is the branding bundle of the org.eclipse.sdk feature. And in its plugin.xml it implements the products extension. So what can you do if you *must* tweak the default Preference for your clients? If you cannot wait for bug 245918 to get fixed, the only workaround I can think of is writing some code that gets executed after the connectorservice.dstore bundle is loaded, and re-sets the Preference to what you need. A dynamic system type declaration might be one possibility to do that ("My DStore").
Since bug 245918 is resolved, can I close this one, Martin?
Definitely yes. The original problem here is resolved, and connection timeouts can be specified by the user.
I believe it can be closed. Could you answer this question for when I am able to use the customization file: The value of this preference is a string "org.eclipse.rse.connectorservice.dstore.ui.preferences.sockettimeout". I guess this means I can't just change it to "20000". I looked in the RSE code for a constant or object with this name and couldn't find it. How does this string resolve to the value 5000?
Created attachment 113258 [details] Product project with sample plugin_customization.ini Denise, attached ZIP file is what I used for testing this. It can be imported as a project into your workspace. The plugin_customization.ini file contains the required setting for changing the dstore connection timeout. When you launch in the Debugger, select this as the product to test. When deploying as a real product, place the plugin_customization.ini into your product's primary plugin (like the org.eclipse.sdk plugin in the Eclipse SDK).
I'm marking this as fixed now since we've resolved the not launching server when there is a null user id problem and bug 245918 is resolved to allow for customizations.
Thanks for all the help!
