Bug 185135

Personal observation: I have not yet managed to increase the limit myself, on my computer (and I tried). I believe that any recommendation without some automatic action is just going to be ignored by 95% of users.

Anyway putting such warning in nbexec is unreasonable, as the warning applies only to NetBeans IDE, not other NetBeans Platform applications.

Also I am afraid that showing such warning on start is going to hurt initial start experience. Rather than that, the check and also fix shall be made part of installation procedure. That is the time the user expects changes to system configuration. Up to Ondřej to decide. 

I'd like to point out that we have a wiki page talking about the topic:
http://wiki.netbeans.org/FaqScanningAndIndexingPerformanceHints#File_Descriptor_Limit_On_UNIX

(In reply to comment #1)
> I have not yet managed to increase the limit myself, on my computer

Which distribution? limits.conf works on Ubuntu. I have heard that some other distributions use a different file for this purpose.

(Are the limits on Mac OS X, Solaris 10, and OpenSolaris set reasonably high by default?)

> putting such warning in nbexec is unreasonable, as the warning applies
> only to NetBeans IDE, not other NetBeans Platform applications.

Right, which is why I wrote "NB (IDE) launcher", i.e. not nbexec.

> the check and also fix shall be made part of installation procedure

Note that this will not help users of ZIP distributions or source builds, including many NetCAT participants. That is why I suggest at least a warning to console in the launcher.

> http://wiki.netbeans.org/FaqScanningAndIndexingPerformanceHints#File_Descriptor_Limit_On_UNIX

Which is fine, but a new user would know to look for that unless they were told about it - they will experience poor performance and assume that this is just normal for NetBeans, never realizing there is a simple fix.

Should also try to increase /etc/sysctl.conf#fs.inotify.max_user_watches now that we do native listening.

I think we need to fix this. Attempting to use the IDE when your ulimit is too low to actually open all module JARs causes a lot of random-looking performance problems and potentially errors too. If you were not prompted to increase your ulimit, it is unlikely you would ever guess this is all that needs to be done.

Planned to be looked at for 7.1.

There are several approaches now:

(1) Check "ulimit -n" in installer and if it is too low, put the warning message with a description and a link to wiki page [*] into the last installer panel.

[*] http://wiki.netbeans.org/FaqOutOfFileDescriptors

"+" Easy to fix and don't overload installer UI too much
"-" Additional configuration operations are required from the user (though it is a usual situation for the active Unix users)

QUESTION: what is "too low" value for "ulimit -n"? Most distributions have 1024 by default. It means the warning will be shown to everyone who haven't change default value (the majority). 

(2) Check "ulimit -n" in installer and if it is too low(?) and the user is authorized for changing /etc files, suggest to change it. Then request sudo password and correct /etc/security/limits.conf file (for Linux) as suggested at [*] and [**]. 

[**]  http://wiki.netbeans.org/FaqScanningAndIndexingPerformanceHints#File_Descriptor_Limit_On_UNIX

"+" No additional configuration operations are required after NetBeans installation
"-" Installer UI will be overloaded with the new panels or dialogs. It is important since it looks like the majority of the Linux users have default value for "ulimit -n" = 1024, so all of them will be suggested to increase the one.
"-" limits.conf settings typically takes effect when the user logs in, so log out/log in will be required to get the advantage of this change
"-" very system dependent, will need a lot of testing on different distributions
"-" Suggestion to change system level settings in installer for IDE may look strange for inexperienced Unix user

(3) Use the approach (1) to let the user know about possible performance issues and how to fix them on a system level. Also try to increase a soft limit locally ("ulimit -n 4096") for the current session in the IDE launcher.  

"+" looks like the most harmonious way
"-" the most Ubuntu distributions are misconfigured by default with a hard limit identical to the soft limit = 1024. So it is impossible to increase the limit without sudo. But this bug is already fixed for Ubuntu Natty, see [***]

[***] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/663090

I would prefer (3). Any comments?

(In reply to comment #6)
> Most distributions have 1024
> by default. It means the warning will be shown to everyone who haven't change
> default value (the majority).

Right... and most Linux users _should_ be incrementing at least the "hard" part of this ulimit. Not only NetBeans can be broken by an artificially low limit.

> "-" limits.conf settings typically takes effect when the user logs in, so log
> out/log in will be required to get the advantage of this change

True, you would need to ask the user to log in again after installation.

> "-" the most Ubuntu distributions are misconfigured by default with a hard
> limit identical to the soft limit = 1024. So it is impossible to increase the
> limit without sudo. But this bug is already fixed for Ubuntu Natty

That is great for people running Natty once that is released, but not helpful before then, and even then not helpful for people using other distributions or LTS versions of Ubuntu.

That said, it would be useful immediately to run ulimit -S -n 4000 (or whatever) in the IDE launcher, and just issue a warning if that command fails (with special advice in case ulimit -H -n reports a low hard limit). This will at least address the problem for those people whose hard limit is high enough but whose soft limit is not.

Assigned to new owner.

As I am browsing exception reports for background scan cancel, sometimes I see  errno: 28 messages logged by org.netbeans.modules.masterfs.watcher.Watcher, which could indicate low descriptor limit. I'll attach the exception reports to this defect.