This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 174532 - User does not understand the reason of failed remote host setup
Summary: User does not understand the reason of failed remote host setup
Status: NEW
Alias: None
Product: cnd
Classification: Unclassified
Component: Remote (show other bugs)
Version: 6.x
Hardware: All All
: P4 blocker (vote)
Assignee: issues@cnd
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-14 12:20 UTC by Vladimir Voskresensky
Modified: 2014-04-14 14:35 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Voskresensky 2009-10-14 12:20:50 UTC
1) Somehow on remote host rfs_controller was left running.
2) locally I restart IDE
3) Try to build project on remote host
4) IDE asks about the password and finishes this process with message in status bar (smth like "Can not copy
...Linux-x86/rfs_controller to host"), but this message disappears very quickly and not clear what to do
5) Try 3) => IDE tells that host is not connected, but that time without asking for password

We have to help user to recover from problem of hanging remote rfs_controller
Comment 1 Vladimir Voskresensky 2009-10-14 12:27:52 UTC
What I'd like to see:
1) Tell me what I should to kill (PIDs) on remote host
or
2) Give me a list or hang remote rfs_controller processes, I check which to kill and IDE will kill them
Comment 2 Leonid Lenyashin 2009-10-14 12:36:09 UTC
This all sounds ridiculous to me.
1) Why should be copy rfs_controller to host if it is already there?
2) Why should we bother a user? Just check if rfs_controler on the remote host is good enough (version?) and leave it as is
3) Beyond host setup there should be an anti-hung logic in rfs_controller. At start it should check if there is one
already running, check if it is alive in some way, if it is then just leave, and if it is not then kill it and continue.

As a user I do not want to know about the rfs_controller.
Comment 3 Vladimir Kvashin 2009-10-15 07:04:50 UTC
Leonid,

Sure we shouldn't copy rfs_controller if it's already there, this was a temporary workaround until the issue 173766
(Binaries in ~/.netbeans/6.8/cnd3 should be up to date) is solved. To solve it we plan using md5 check sums.

As to anti-hang logic: we should think this over. Anyhow, we launch an instance of the rfs_controller for each build, so
in general, the presence of several running rfs_controllers does not mean one of them hung.
Comment 4 Vladimir Kvashin 2009-11-12 08:02:25 UTC
The rfs binaries copying algorithm has been changed:
- they are copied to /var/tmp/..., not to the home
- only binaries that are relevant to the target platform are copied
- md5 sums are checked first, so binaries aren't copied if they are the same

However in theory, the issue still exists. Error processing and communicating issues to user should be better, I believe.
Comment 5 Alexander Pepin 2010-03-26 16:26:01 UTC
As "...However in theory, the issue still exists.." then it's not a P3.