DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG� RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=34140>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND� INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=34140 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From [EMAIL PROTECTED] 2005-05-12 01:37 ------- Thank you for the new solution. However I re-opened this record because the change does not fully fix the bug. Fully fixing it should be easy after the main work has already been done. Background: ----------- The new solution is too complicated in a commercial environment. The main reason for this is as follows: Generally speaking, polling loops are temporary workarounds that should be eliminated as soon as other methods such as interrupts or callbacks are available. I apologise if my own workaround example has inspired the new solution. Please consider that the problem at hand is very common in computer programming, which explains the existence of various techniques that solve the issue at hand in better ways. One of them, probably not ideal for this issue, is FAM, the File Alteration Monitor, that provides a daemon and an API which applications can use for notification of changes in specific files or directories. This is installed with out-of-the-box RedHat Linux distributions. Being a workaround, the current jsvc solution should NOT manifest itself in an additional parameter (syntax) that would have to be discontinued after a better solution is implemented. To back up this claim, it has to be said that there are virtually no instances across many environments and languages of common commands that require a timeout parameter. The simple reason for this is that in most computer languages, most commands are blocking, returning only after the task is completed. The task at hand here is the initialisation and starting of a daemon/service. Suggestions: ------------ The -wait parameter should be removed while the blocking behavior should be retained. Question: How can jsvc block without a -wait parameter? Answer: jsvc should not return until the service is started. If it took an infinite time, then jsvc simply would not return. Specifics: a) If no other solution than a polling loop is available, then the polling frequency should be fixed, in the order of 10 loops per second. The current new solution appears to have a fixed but lower polling frequency. b) jsvc should ALWAYS block; it should never return before (or significantly after) startup of the service or in case of errors. There is no compelling reason why it should not do so. Having a -wait parameter is confusing. If an application wants non-blocking behavior, then it is trivial for this application to do that whith a blocking jsvc by means of launching jsvc in a separate process. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
