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 192129 - [70cat][uninstall] nbi-cleaner process remains after uninstall is completed
Summary: [70cat][uninstall] nbi-cleaner process remains after uninstall is completed
Status: REOPENED
Alias: None
Product: apisupport
Classification: Unclassified
Component: NBI (show other bugs)
Version: 7.1
Hardware: PC Windows XP
: P3 normal (vote)
Assignee: Libor Fischmeistr
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-18 18:47 UTC by esmithbss
Modified: 2015-07-30 08:03 UTC (History)
2 users (show)

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 esmithbss 2010-11-18 18:47:14 UTC
[ BUILD # : 201011160001 ]
[ JDK VERSION : 1.6.22 ]

When uninstalling NetBeans, the nbi-cleaner process which is launched during
the uninstall remains processing long after the uninstall is completed.

If multiple install/uninstall operations are performed, there are multiple
nbi-cleaner process which remain visible within the Windows TaskManager.
Comment 1 Jiri Rechtacek 2011-11-10 10:07:23 UTC
esmithbss, is it still reproducible with recent dev builds of NetBeans 7.1? Thanks
Comment 2 Sergey Grinev 2013-02-13 08:16:46 UTC
just reproduced with uninstalling of NetBeans 7.1
Comment 3 Libor Fischmeistr 2013-02-13 08:28:51 UTC
(In reply to comment #2)
> just reproduced with uninstalling of NetBeans 7.1

Hi, thanks for the report. Are you able to reproduce it with latest installer/uninstaller?

Thanks in advance for the response.
Comment 4 jalex 2013-11-21 22:33:38 UTC
I had this issue this week with Netbeans 7.3 and 7.4 (including the one I downloaded on Nov 19, 2013.  I was suprised to see a cmd.exe process running nbi-cleaner (two actually, because I uninstalled 7.3, installed 7.4), using most of my CPU for the better part of a day or two.
Comment 5 phansson 2013-12-05 13:32:04 UTC
Have reproduced on NB 7.4, Windows 7, 64 bit.

The nbi-cleaner process is 'hanging'.

Btw: Using Maven-generated installer which can potentially use a NBI Harness from a previous version so cannot really say for sure that this is NB 7.4 related even if generated on an NB 7.4 platform. Indeed the current latest version of the nbm-maven-plugin (v3.11.1) still uses the 7.3 Harness. Not sure it matters to this bug report though. Just thought I would mention it.

The nbi-cleaner processes that I have as leftovers have all been created as a result of cancelling the installation process.

Please let us know what can be done to get to the bottom of this. I'll be glad to do some debugging, etc, but I'll need to know what to turn on .. and how.
Comment 6 phansson 2013-12-05 13:53:33 UTC
Wrong info previously (from me): The nbi-cleaner process that gets left behind are from the Maven "nbm:build-installers" process, not from actually executing the installer.  Why the Maven build process actually executes the cleaner beats me but there's probably a good reason.

When my Maven build runs and I monitor my Windows processes at the same time I can for a short while actually see *two* cleaner processes. One of them gets left behind and never finishes. Everytime you do a Maven build of the installers a new nbi-cleaner process gets left behind.

I can consistently reproduce on a fresh (i.e. no code) Maven NetBeans Platform application.
Comment 7 Jiri Rechtacek 2013-12-05 13:58:56 UTC
(In reply to phansson from comment #5)
> The nbi-cleaner processes that I have as leftovers have all been created as
> a result of cancelling the installation process.
This might be relevant for understand the problem.
Comment 8 phansson 2013-12-05 14:30:57 UTC
(In reply to Jiri Rechtacek from comment #7)
> (In reply to phansson from comment #5)
> > The nbi-cleaner processes that I have as leftovers have all been created as
> > a result of cancelling the installation process.
> This might be relevant for understand the problem.

Yeh, well, unfortunately that info was wrong. See comment #6.
Comment 9 phansson 2015-07-30 08:03:25 UTC
I've spent quite some time with the cleaner so I just wanted to explain exactly what it does and why you may still see it as a process after an install/uninstall process:

The "cleaner" is a small native application which is part of the NetBeans Installer (NBI) infrastructure. The job of the cleaner is to delete files which the JVM process for some reason cannot delete itself. Java has its own deleteOnExit() method but that method is pretty useless as it cannot delete files that the JVM itself uses.

The cleaner gets launched from Java at the end of the NBI install/uninstall process (from a shutdown hook). It gets launched in such a clever way that it becomes detached from the JVM process itself, hence it will live on even when the JVM process closes (i.e. the actual installer process). On Unices such a process would be known as a 'daemon' and is created by a technique called double-fork. On Windows this is known as a 'process without handles'. Java doesn't support spawning such a process so NBI has to rely on native calls for this purpose.

The cleaner works off a list of files to delete. It gets passed this list of files as an argument on the command line. The list is in a temporary file. The cleaner deletes this file after it has read it. The list of files is supposed to be ordered so the delete happens in the right sequence (you cannot delete a directory before you've deleted all files in it). This ordering is done automatically by the NBI Engine (nbi-engine.jar) so this not something anyone creating an installer should worry about.

The cleaner can delete both files and directories (if they are empty).

On Windows the cleaner is a very small C program. It is (at the moment) always 32-bit regardless of JVM or Windows version.


How does the cleaner work on Windows ?

After launch the cleaner will read the list of files to delete from a temporary file. The list of files to delete is read into memory and the temporary file can therefore be deleted immediately after it has been read.

Then the cleaner sleeps for 2 seconds. This is to allow the JVM process that has started it to close down.

The cleaner will then loop over the list of files to delete. Each file-delete operation is spawned into a thread of its own up to a maximum of 64 threads. Therefore the delete operations happens in parallel rather than in sequence. (Note: I find this design somewhat dangerous as the order of delete can be quite important. However I have not seen the cleaner fail as a result of this).

For each delete operation the cleaner will do the following:

- Checks to see if the file exists (by getting its attributes)
- If file: delete file, if directory: delete directory (these are two different calls in the Win32 API).
- Attempt to delete each file/dir up to 15 times sleeping for 200 ms between each attempt.

If there are no available threads (i.e. there more than 64 files to delete) then the cleaner process will wait until a there are less than 64 active threads. In other words: At any point in time there are never more than 64 active threads.

The cleaner process has absolutely no logging features so it is pretty difficult so say what it does if something goes wrong.

If the cleaner cannot delete a file it is obvious that you'll see the cleaner process around for at least 5 seconds (2 secs + (15*200ms)) and possibly more if it is deleting more than 64 files. I would say, however, that it should never exist for more than say 10-15 secs.