Menu
▾
▴
naviserver-tracker — SourceForge Tracker Notifications
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(61) |
Mar
(153) |
Apr
(39) |
May
(10) |
Jun
(15) |
Jul
(15) |
Aug
(2) |
Sep
|
Oct
(17) |
Nov
(2) |
Dec
(13) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(18) |
Feb
(9) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(7) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
|
| 2007 |
Jan
(8) |
Feb
(3) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
(6) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2005-07-08 12:01:37
|
Bugs item #1231853, was opened at 2005-07-03 11:14 Message generated for change (Comment added) made by sdeasey You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719006&aid=1231853&group_id=130646 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Current Status: Open Resolution: None Priority: 5 Submitted By: Bernd Eidenschink (eide) >Assigned to: Stephen Deasey (sdeasey) Summary: Incomplete config file leading server to unusable state Initial Comment: I'm not 100% sure if this behaviour should be classified as Bug, lets see. I found that at a bare minimum the server needs something like this to start: --------------------------------------------------- set servername "server1" set serverdesc "My first server" set homedir [file dirname [ns_info config]] ns_section "ns/servers" ns_param $servername $serverdesc ns_section "ns/parameters" ns_param home $homedir --------------------------------------------------- when starting the server with: ./nsd -u nsadmin -g www -f -t ../smallest-config.tcl it says (timestamps and threadinfo deleted): [-main-] Notice: nsmain: NaviServer/4.99.0 starting [-main-] Notice: nsmain: security info: uid=1003, euid=1003, gid=8, egid=8 [-main-] Notice: nsmain: max files: FD_SETSIZE = 1024, rl_cur = 1024, rl_max = 1024 [-main-] Notice: conf: [ns/server/server1]enabletclpages = 0 [-main-] Notice: nsmain: NaviServer/4.99.0 running [-main-] Notice: nsmain: security info: uid=1003, euid=1003, gid=8, egid=8 and waits. It's visible in the process list (ps shows 2 threads), but not binding to a port ('lsof -i' shows no nsd). When stopping the Server with Ctrl-C: [-main-] Notice: nsmain: NaviServer/4.99.0 stopping [-main-] Notice: driver: triggering shutdown [-main-] Fatal: driver: trigger send() failed: Socket operation on non-socket If it is not considered to be a bug there should at least be some log notice like: "Hint: You may have to specify... " or "Incomplete Configuration...." or not start at all. ---------------------------------------------------------------------- >Comment By: Stephen Deasey (sdeasey) Date: 2005-07-08 06:01 Message: Logged In: YES user_id=87254 That's what I was wondering, does anyone have a use for this? 4 it is then, the server will log a warning if no drivers are configured. I'll add this. ---------------------------------------------------------------------- Comment By: Zoran Vasiljevic (vasiljevic) Date: 2005-07-07 01:07 Message: Logged In: YES user_id=95086 The option of 4 is actually OK. I can cook up an application with Tcl using NS as MT-app server having no visible network connections. I would not stop the server if no drivers are loaded, but a warning log seems OK. ---------------------------------------------------------------------- Comment By: Bernd Eidenschink (eide) Date: 2005-07-06 04:23 Message: Logged In: YES user_id=197910 Hm, I tend to Option (3); But just because I can't imagine a use case for (4), is there? Or is it then just a tclsh gone wild? ---------------------------------------------------------------------- Comment By: Stephen Deasey (sdeasey) Date: 2005-07-06 03:45 Message: Logged In: YES user_id=87254 If the only configured driver fails to bind an error is logged but the server starts successfully. I'm not sure how useful a naviserver with no listening drivers is..? But you're right, not specifying any drivers should not leave the server in limbo -- it should either start or it should fail. So here's some options: 1) not specifying any drivers is a fatal error 2) not specifying any drivers is ok (log warning?) 3) no listening drivers for any reason is a fatal error 4) no listening drivers is ok (log warning?) I think maybe option 4, with a warning. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719006&aid=1231853&group_id=130646 |
|
From: SourceForge.net <no...@so...> - 2005-07-08 10:10:51
|
Bugs item #1230150, was opened at 2005-06-29 23:42 Message generated for change (Comment added) made by sdeasey You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719006&aid=1230150&group_id=130646 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tcl-API Group: Current Status: Open Resolution: None Priority: 5 Submitted By: Bernd Eidenschink (eide) Assigned to: Nobody/Anonymous (nobody) Summary: ns_log Fatal does not shutdown server Initial Comment: In nsd/log.c one noted side effect of the severity flag "fatal" given to ns_log is "WILL CAUSE AOLSERVER TO EXIT!". AFAIK this does not work, e.g. in command mode NaviServer happily logs but does not exit. ---------------------------------------------------------------------- >Comment By: Stephen Deasey (sdeasey) Date: 2005-07-08 04:10 Message: Logged In: YES user_id=87254 The Fatal log level is used only twice in the source code: once in the Ns_Fatal command which then calls _exit(), and once in the fatal signal handler which then calls abort(). I don't think you can have Ns_Log exit the process. Tcl code should not, in general, be logging fatal errors because, in general, it's hard to get Tcl fataly wrong. I was saying it would be a bad design to ns_log fatal, not that there aren't other ways to shutdown the server and we need to hide them... :-) The only thing I'd change is the documentation: don't mention 'fatal' as a valid level in the Tcl docs. ---------------------------------------------------------------------- Comment By: Zoran Vasiljevic (vasiljevic) Date: 2005-07-07 01:03 Message: Logged In: YES user_id=95086 The "fatal" severity would/should trigger server to go down. Even from Tcl scripts. Otherwise the "fatal" has no real meaning. ---------------------------------------------------------------------- Comment By: Bernd Eidenschink (eide) Date: 2005-07-06 04:31 Message: Logged In: YES user_id=197910 >I'm not sure whether it's a good idea for Tcl procs to >shutdown the server like that. It should be prety difficult >to get into a 'Fatal' situation with Tcl... But they can already do 'ns_shutdown (-restart)'. And many, many more nasty things ;-) IMHO, without a general concept to disarm the developers and their scripts, it should shutdown the server. At least it was always documented that way (in the ancient docs) and people believed it :-) Or we make it a config option: ns_param ShutdownAtFatal true ? ---------------------------------------------------------------------- Comment By: Stephen Deasey (sdeasey) Date: 2005-07-06 03:26 Message: Logged In: YES user_id=87254 This comment goes with the function Ns_Fatal(), which does indeed call _exit(1) which should shutdown the server :-) I'm not sure whether it's a good idea for Tcl procs to shutdown the server like that. It should be prety difficult to get into a 'Fatal' situation with Tcl... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719006&aid=1230150&group_id=130646 |
|
From: SourceForge.net <no...@so...> - 2005-07-07 07:07:11
|
Bugs item #1231853, was opened at 2005-07-03 19:14 Message generated for change (Comment added) made by vasiljevic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719006&aid=1231853&group_id=130646 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Current Status: Open Resolution: None Priority: 5 Submitted By: Bernd Eidenschink (eide) Assigned to: Nobody/Anonymous (nobody) Summary: Incomplete config file leading server to unusable state Initial Comment: I'm not 100% sure if this behaviour should be classified as Bug, lets see. I found that at a bare minimum the server needs something like this to start: --------------------------------------------------- set servername "server1" set serverdesc "My first server" set homedir [file dirname [ns_info config]] ns_section "ns/servers" ns_param $servername $serverdesc ns_section "ns/parameters" ns_param home $homedir --------------------------------------------------- when starting the server with: ./nsd -u nsadmin -g www -f -t ../smallest-config.tcl it says (timestamps and threadinfo deleted): [-main-] Notice: nsmain: NaviServer/4.99.0 starting [-main-] Notice: nsmain: security info: uid=1003, euid=1003, gid=8, egid=8 [-main-] Notice: nsmain: max files: FD_SETSIZE = 1024, rl_cur = 1024, rl_max = 1024 [-main-] Notice: conf: [ns/server/server1]enabletclpages = 0 [-main-] Notice: nsmain: NaviServer/4.99.0 running [-main-] Notice: nsmain: security info: uid=1003, euid=1003, gid=8, egid=8 and waits. It's visible in the process list (ps shows 2 threads), but not binding to a port ('lsof -i' shows no nsd). When stopping the Server with Ctrl-C: [-main-] Notice: nsmain: NaviServer/4.99.0 stopping [-main-] Notice: driver: triggering shutdown [-main-] Fatal: driver: trigger send() failed: Socket operation on non-socket If it is not considered to be a bug there should at least be some log notice like: "Hint: You may have to specify... " or "Incomplete Configuration...." or not start at all. ---------------------------------------------------------------------- >Comment By: Zoran Vasiljevic (vasiljevic) Date: 2005-07-07 09:07 Message: Logged In: YES user_id=95086 The option of 4 is actually OK. I can cook up an application with Tcl using NS as MT-app server having no visible network connections. I would not stop the server if no drivers are loaded, but a warning log seems OK. ---------------------------------------------------------------------- Comment By: Bernd Eidenschink (eide) Date: 2005-07-06 12:23 Message: Logged In: YES user_id=197910 Hm, I tend to Option (3); But just because I can't imagine a use case for (4), is there? Or is it then just a tclsh gone wild? ---------------------------------------------------------------------- Comment By: Stephen Deasey (sdeasey) Date: 2005-07-06 11:45 Message: Logged In: YES user_id=87254 If the only configured driver fails to bind an error is logged but the server starts successfully. I'm not sure how useful a naviserver with no listening drivers is..? But you're right, not specifying any drivers should not leave the server in limbo -- it should either start or it should fail. So here's some options: 1) not specifying any drivers is a fatal error 2) not specifying any drivers is ok (log warning?) 3) no listening drivers for any reason is a fatal error 4) no listening drivers is ok (log warning?) I think maybe option 4, with a warning. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719006&aid=1231853&group_id=130646 |
|
From: SourceForge.net <no...@so...> - 2005-07-07 07:03:40
|
Bugs item #1230150, was opened at 2005-06-30 07:42 Message generated for change (Comment added) made by vasiljevic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719006&aid=1230150&group_id=130646 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tcl-API Group: Current Status: Open Resolution: None Priority: 5 Submitted By: Bernd Eidenschink (eide) Assigned to: Nobody/Anonymous (nobody) Summary: ns_log Fatal does not shutdown server Initial Comment: In nsd/log.c one noted side effect of the severity flag "fatal" given to ns_log is "WILL CAUSE AOLSERVER TO EXIT!". AFAIK this does not work, e.g. in command mode NaviServer happily logs but does not exit. ---------------------------------------------------------------------- >Comment By: Zoran Vasiljevic (vasiljevic) Date: 2005-07-07 09:03 Message: Logged In: YES user_id=95086 The "fatal" severity would/should trigger server to go down. Even from Tcl scripts. Otherwise the "fatal" has no real meaning. ---------------------------------------------------------------------- Comment By: Bernd Eidenschink (eide) Date: 2005-07-06 12:31 Message: Logged In: YES user_id=197910 >I'm not sure whether it's a good idea for Tcl procs to >shutdown the server like that. It should be prety difficult >to get into a 'Fatal' situation with Tcl... But they can already do 'ns_shutdown (-restart)'. And many, many more nasty things ;-) IMHO, without a general concept to disarm the developers and their scripts, it should shutdown the server. At least it was always documented that way (in the ancient docs) and people believed it :-) Or we make it a config option: ns_param ShutdownAtFatal true ? ---------------------------------------------------------------------- Comment By: Stephen Deasey (sdeasey) Date: 2005-07-06 11:26 Message: Logged In: YES user_id=87254 This comment goes with the function Ns_Fatal(), which does indeed call _exit(1) which should shutdown the server :-) I'm not sure whether it's a good idea for Tcl procs to shutdown the server like that. It should be prety difficult to get into a 'Fatal' situation with Tcl... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719006&aid=1230150&group_id=130646 |
|
From: SourceForge.net <no...@so...> - 2005-07-06 10:31:49
|
Bugs item #1230150, was opened at 2005-06-30 05:42 Message generated for change (Comment added) made by eide You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719006&aid=1230150&group_id=130646 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tcl-API Group: Current Status: Open Resolution: None Priority: 5 Submitted By: Bernd Eidenschink (eide) Assigned to: Nobody/Anonymous (nobody) Summary: ns_log Fatal does not shutdown server Initial Comment: In nsd/log.c one noted side effect of the severity flag "fatal" given to ns_log is "WILL CAUSE AOLSERVER TO EXIT!". AFAIK this does not work, e.g. in command mode NaviServer happily logs but does not exit. ---------------------------------------------------------------------- >Comment By: Bernd Eidenschink (eide) Date: 2005-07-06 10:31 Message: Logged In: YES user_id=197910 >I'm not sure whether it's a good idea for Tcl procs to >shutdown the server like that. It should be prety difficult >to get into a 'Fatal' situation with Tcl... But they can already do 'ns_shutdown (-restart)'. And many, many more nasty things ;-) IMHO, without a general concept to disarm the developers and their scripts, it should shutdown the server. At least it was always documented that way (in the ancient docs) and people believed it :-) Or we make it a config option: ns_param ShutdownAtFatal true ? ---------------------------------------------------------------------- Comment By: Stephen Deasey (sdeasey) Date: 2005-07-06 09:26 Message: Logged In: YES user_id=87254 This comment goes with the function Ns_Fatal(), which does indeed call _exit(1) which should shutdown the server :-) I'm not sure whether it's a good idea for Tcl procs to shutdown the server like that. It should be prety difficult to get into a 'Fatal' situation with Tcl... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719006&aid=1230150&group_id=130646 |
|
From: SourceForge.net <no...@so...> - 2005-07-06 10:23:31
|
Bugs item #1231853, was opened at 2005-07-03 17:14 Message generated for change (Comment added) made by eide You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719006&aid=1231853&group_id=130646 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Current Status: Open Resolution: None Priority: 5 Submitted By: Bernd Eidenschink (eide) Assigned to: Nobody/Anonymous (nobody) Summary: Incomplete config file leading server to unusable state Initial Comment: I'm not 100% sure if this behaviour should be classified as Bug, lets see. I found that at a bare minimum the server needs something like this to start: --------------------------------------------------- set servername "server1" set serverdesc "My first server" set homedir [file dirname [ns_info config]] ns_section "ns/servers" ns_param $servername $serverdesc ns_section "ns/parameters" ns_param home $homedir --------------------------------------------------- when starting the server with: ./nsd -u nsadmin -g www -f -t ../smallest-config.tcl it says (timestamps and threadinfo deleted): [-main-] Notice: nsmain: NaviServer/4.99.0 starting [-main-] Notice: nsmain: security info: uid=1003, euid=1003, gid=8, egid=8 [-main-] Notice: nsmain: max files: FD_SETSIZE = 1024, rl_cur = 1024, rl_max = 1024 [-main-] Notice: conf: [ns/server/server1]enabletclpages = 0 [-main-] Notice: nsmain: NaviServer/4.99.0 running [-main-] Notice: nsmain: security info: uid=1003, euid=1003, gid=8, egid=8 and waits. It's visible in the process list (ps shows 2 threads), but not binding to a port ('lsof -i' shows no nsd). When stopping the Server with Ctrl-C: [-main-] Notice: nsmain: NaviServer/4.99.0 stopping [-main-] Notice: driver: triggering shutdown [-main-] Fatal: driver: trigger send() failed: Socket operation on non-socket If it is not considered to be a bug there should at least be some log notice like: "Hint: You may have to specify... " or "Incomplete Configuration...." or not start at all. ---------------------------------------------------------------------- >Comment By: Bernd Eidenschink (eide) Date: 2005-07-06 10:23 Message: Logged In: YES user_id=197910 Hm, I tend to Option (3); But just because I can't imagine a use case for (4), is there? Or is it then just a tclsh gone wild? ---------------------------------------------------------------------- Comment By: Stephen Deasey (sdeasey) Date: 2005-07-06 09:45 Message: Logged In: YES user_id=87254 If the only configured driver fails to bind an error is logged but the server starts successfully. I'm not sure how useful a naviserver with no listening drivers is..? But you're right, not specifying any drivers should not leave the server in limbo -- it should either start or it should fail. So here's some options: 1) not specifying any drivers is a fatal error 2) not specifying any drivers is ok (log warning?) 3) no listening drivers for any reason is a fatal error 4) no listening drivers is ok (log warning?) I think maybe option 4, with a warning. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719006&aid=1231853&group_id=130646 |
|
From: SourceForge.net <no...@so...> - 2005-07-06 09:45:22
|
Bugs item #1231853, was opened at 2005-07-03 11:14 Message generated for change (Comment added) made by sdeasey You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719006&aid=1231853&group_id=130646 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Current Status: Open Resolution: None Priority: 5 Submitted By: Bernd Eidenschink (eide) Assigned to: Nobody/Anonymous (nobody) Summary: Incomplete config file leading server to unusable state Initial Comment: I'm not 100% sure if this behaviour should be classified as Bug, lets see. I found that at a bare minimum the server needs something like this to start: --------------------------------------------------- set servername "server1" set serverdesc "My first server" set homedir [file dirname [ns_info config]] ns_section "ns/servers" ns_param $servername $serverdesc ns_section "ns/parameters" ns_param home $homedir --------------------------------------------------- when starting the server with: ./nsd -u nsadmin -g www -f -t ../smallest-config.tcl it says (timestamps and threadinfo deleted): [-main-] Notice: nsmain: NaviServer/4.99.0 starting [-main-] Notice: nsmain: security info: uid=1003, euid=1003, gid=8, egid=8 [-main-] Notice: nsmain: max files: FD_SETSIZE = 1024, rl_cur = 1024, rl_max = 1024 [-main-] Notice: conf: [ns/server/server1]enabletclpages = 0 [-main-] Notice: nsmain: NaviServer/4.99.0 running [-main-] Notice: nsmain: security info: uid=1003, euid=1003, gid=8, egid=8 and waits. It's visible in the process list (ps shows 2 threads), but not binding to a port ('lsof -i' shows no nsd). When stopping the Server with Ctrl-C: [-main-] Notice: nsmain: NaviServer/4.99.0 stopping [-main-] Notice: driver: triggering shutdown [-main-] Fatal: driver: trigger send() failed: Socket operation on non-socket If it is not considered to be a bug there should at least be some log notice like: "Hint: You may have to specify... " or "Incomplete Configuration...." or not start at all. ---------------------------------------------------------------------- >Comment By: Stephen Deasey (sdeasey) Date: 2005-07-06 03:45 Message: Logged In: YES user_id=87254 If the only configured driver fails to bind an error is logged but the server starts successfully. I'm not sure how useful a naviserver with no listening drivers is..? But you're right, not specifying any drivers should not leave the server in limbo -- it should either start or it should fail. So here's some options: 1) not specifying any drivers is a fatal error 2) not specifying any drivers is ok (log warning?) 3) no listening drivers for any reason is a fatal error 4) no listening drivers is ok (log warning?) I think maybe option 4, with a warning. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719006&aid=1231853&group_id=130646 |
|
From: SourceForge.net <no...@so...> - 2005-07-06 09:26:49
|
Bugs item #1230150, was opened at 2005-06-29 23:42 Message generated for change (Comment added) made by sdeasey You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719006&aid=1230150&group_id=130646 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tcl-API Group: Current Status: Open Resolution: None Priority: 5 Submitted By: Bernd Eidenschink (eide) Assigned to: Nobody/Anonymous (nobody) Summary: ns_log Fatal does not shutdown server Initial Comment: In nsd/log.c one noted side effect of the severity flag "fatal" given to ns_log is "WILL CAUSE AOLSERVER TO EXIT!". AFAIK this does not work, e.g. in command mode NaviServer happily logs but does not exit. ---------------------------------------------------------------------- >Comment By: Stephen Deasey (sdeasey) Date: 2005-07-06 03:26 Message: Logged In: YES user_id=87254 This comment goes with the function Ns_Fatal(), which does indeed call _exit(1) which should shutdown the server :-) I'm not sure whether it's a good idea for Tcl procs to shutdown the server like that. It should be prety difficult to get into a 'Fatal' situation with Tcl... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719006&aid=1230150&group_id=130646 |
|
From: SourceForge.net <no...@so...> - 2005-07-03 17:14:22
|
Bugs item #1231853, was opened at 2005-07-03 17:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719006&aid=1231853&group_id=130646 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Current Status: Open Resolution: None Priority: 5 Submitted By: Bernd Eidenschink (eide) Assigned to: Nobody/Anonymous (nobody) Summary: Incomplete config file leading server to unusable state Initial Comment: I'm not 100% sure if this behaviour should be classified as Bug, lets see. I found that at a bare minimum the server needs something like this to start: --------------------------------------------------- set servername "server1" set serverdesc "My first server" set homedir [file dirname [ns_info config]] ns_section "ns/servers" ns_param $servername $serverdesc ns_section "ns/parameters" ns_param home $homedir --------------------------------------------------- when starting the server with: ./nsd -u nsadmin -g www -f -t ../smallest-config.tcl it says (timestamps and threadinfo deleted): [-main-] Notice: nsmain: NaviServer/4.99.0 starting [-main-] Notice: nsmain: security info: uid=1003, euid=1003, gid=8, egid=8 [-main-] Notice: nsmain: max files: FD_SETSIZE = 1024, rl_cur = 1024, rl_max = 1024 [-main-] Notice: conf: [ns/server/server1]enabletclpages = 0 [-main-] Notice: nsmain: NaviServer/4.99.0 running [-main-] Notice: nsmain: security info: uid=1003, euid=1003, gid=8, egid=8 and waits. It's visible in the process list (ps shows 2 threads), but not binding to a port ('lsof -i' shows no nsd). When stopping the Server with Ctrl-C: [-main-] Notice: nsmain: NaviServer/4.99.0 stopping [-main-] Notice: driver: triggering shutdown [-main-] Fatal: driver: trigger send() failed: Socket operation on non-socket If it is not considered to be a bug there should at least be some log notice like: "Hint: You may have to specify... " or "Incomplete Configuration...." or not start at all. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719006&aid=1231853&group_id=130646 |
|
From: SourceForge.net <no...@so...> - 2005-06-30 07:58:06
|
Bugs item #1230179, was opened at 2005-06-30 09:17 Message generated for change (Comment added) made by vasiljevic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719006&aid=1230179&group_id=130646 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: C-API Group: Current >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Bernd Eidenschink (eide) Assigned to: Nobody/Anonymous (nobody) Summary: ns_startcontent crashes server when called in command mode Initial Comment: When starting NaviServer with "-c" and running this script: foreach command [info commands ns_*] { puts "dumb eval of $command..." if {$command ne "ns_shutdown"} { catch { eval $command } err } } it creates a memory access error when running ns_startcontent. This is not the case when placing ns_startcontent e.g. in an ADP file. Tested against current HEAD, server compiled against TCL HEAD on SuSE 9.2. ---------------------------------------------------------------------- >Comment By: Zoran Vasiljevic (vasiljevic) Date: 2005-06-30 09:57 Message: Logged In: YES user_id=95086 Fixed in head. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719006&aid=1230179&group_id=130646 |
|
From: SourceForge.net <no...@so...> - 2005-06-30 07:17:30
|
Bugs item #1230179, was opened at 2005-06-30 07:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719006&aid=1230179&group_id=130646 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: C-API Group: Current Status: Open Resolution: None Priority: 5 Submitted By: Bernd Eidenschink (eide) Assigned to: Nobody/Anonymous (nobody) Summary: ns_startcontent crashes server when called in command mode Initial Comment: When starting NaviServer with "-c" and running this script: foreach command [info commands ns_*] { puts "dumb eval of $command..." if {$command ne "ns_shutdown"} { catch { eval $command } err } } it creates a memory access error when running ns_startcontent. This is not the case when placing ns_startcontent e.g. in an ADP file. Tested against current HEAD, server compiled against TCL HEAD on SuSE 9.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719006&aid=1230179&group_id=130646 |
|
From: SourceForge.net <no...@so...> - 2005-06-30 05:42:19
|
Bugs item #1230150, was opened at 2005-06-30 05:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719006&aid=1230150&group_id=130646 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tcl-API Group: Current Status: Open Resolution: None Priority: 5 Submitted By: Bernd Eidenschink (eide) Assigned to: Nobody/Anonymous (nobody) Summary: ns_log Fatal does not shutdown server Initial Comment: In nsd/log.c one noted side effect of the severity flag "fatal" given to ns_log is "WILL CAUSE AOLSERVER TO EXIT!". AFAIK this does not work, e.g. in command mode NaviServer happily logs but does not exit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719006&aid=1230150&group_id=130646 |
|
From: SourceForge.net <no...@so...> - 2005-06-29 02:23:22
|
Feature Requests item #1229138, was opened at 2005-06-28 16:14 Message generated for change (Settings changed) made by seryakov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1229138&group_id=130646 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: C-API Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Vlad Seryakov (seryakov) Assigned to: Vlad Seryakov (seryakov) Summary: Range: support Initial Comment: I modified fastpath to support Range: headers in the request. Pretty simple and does not affect existing processing. ---------------------------------------------------------------------- Comment By: Zoran Vasiljevic (vasiljevic) Date: 2005-06-28 16:34 Message: Logged In: YES user_id=95086 Do not forget to update the news file since this might be interesting for people when looking-up what is different between us and AS. Also, to increase code readability, I'd make a private call which given the connection headers will return NS_OK or NS_ERROR and would place the computed offset and size in some per-ref pointers. This way it is easier to follow the code, IMO, and the parsing of Range headers does not clutter the rest (of the code). What I also think: the http result codes like 416, 206 etc should be enumerated or #define'd so it is clearer for the ocassional reader what is actually being done. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1229138&group_id=130646 |
|
From: SourceForge.net <no...@so...> - 2005-06-28 16:34:24
|
Feature Requests item #1229138, was opened at 2005-06-28 18:14 Message generated for change (Comment added) made by vasiljevic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1229138&group_id=130646 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: C-API Group: None Status: Open Resolution: None Priority: 5 Submitted By: Vlad Seryakov (seryakov) Assigned to: Vlad Seryakov (seryakov) Summary: Range: support Initial Comment: I modified fastpath to support Range: headers in the request. Pretty simple and does not affect existing processing. ---------------------------------------------------------------------- >Comment By: Zoran Vasiljevic (vasiljevic) Date: 2005-06-28 18:34 Message: Logged In: YES user_id=95086 Do not forget to update the news file since this might be interesting for people when looking-up what is different between us and AS. Also, to increase code readability, I'd make a private call which given the connection headers will return NS_OK or NS_ERROR and would place the computed offset and size in some per-ref pointers. This way it is easier to follow the code, IMO, and the parsing of Range headers does not clutter the rest (of the code). What I also think: the http result codes like 416, 206 etc should be enumerated or #define'd so it is clearer for the ocassional reader what is actually being done. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1229138&group_id=130646 |
|
From: SourceForge.net <no...@so...> - 2005-06-28 16:14:23
|
Feature Requests item #1229138, was opened at 2005-06-28 16:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1229138&group_id=130646 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: C-API Group: None Status: Open Resolution: None Priority: 5 Submitted By: Vlad Seryakov (seryakov) Assigned to: Vlad Seryakov (seryakov) Summary: Range: support Initial Comment: I modified fastpath to support Range: headers in the request. Pretty simple and does not affect existing processing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1229138&group_id=130646 |
|
From: SourceForge.net <no...@so...> - 2005-06-17 19:22:49
|
Feature Requests item #1202462, was opened at 2005-05-15 22:14 Message generated for change (Comment added) made by vasiljevic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1202462&group_id=130646 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: C-API Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zoran Vasiljevic (vasiljevic) Assigned to: Zoran Vasiljevic (vasiljevic) Summary: Rewrite to use Tcl VFS filesystem abstraction Initial Comment: We should really invest some time and rewrite all (most?) of the internal usages of open(), stat() (etc) so we can take advantage of Tcl virtual filesystem wappers. ---------------------------------------------------------------------- >Comment By: Zoran Vasiljevic (vasiljevic) Date: 2005-06-17 21:22 Message: Logged In: YES user_id=95086 OK. I will proceede as agreed. FYI, the fastpath code will use mmap only if fastpath.map is turned on fastpath cache is disabled or entry is too large for the cache. Only under those circumstances, the mmap is attempted. ---------------------------------------------------------------------- Comment By: Stephen Deasey (sdeasey) Date: 2005-06-17 21:15 Message: Logged In: YES user_id=87254 Basically, YES. I don't think you need the vfs configuration flag. The check to see if mmap is enabled comes before the vfs flag in the fastpath code, so no matter what you set vfs to, it may be overidden by mmap. You should drop the vfs flag and make vfs the default if mmap is not enabled (as that is currently the only other option). i.e. also drop the fallback to normal open() etc. if vfs is not enabled. The original concern was that the file descriptor would not be available so that more advanced IO calls could be used, not that Tcl_VFSOpen() is noticably slower than open() etc. But you've shown how to deal with that, so I think just use Tcl VFS throughout, for simplicity. The same applies to the adp code, just use Tcl VFS. Any possible minor slowdown when accessing the file sytem should be hidden by the ADP memory cache anyway. So, the instruction for folks who want to use the Tcl VFS hooks to overide normal FS processing would be to make sure mmap (currently, plus any future optimisation) is turned off. ---------------------------------------------------------------------- Comment By: Zoran Vasiljevic (vasiljevic) Date: 2005-06-17 11:58 Message: Logged In: YES user_id=95086 This is how I plan to proceede on this topic. 1. Rewrite all filesystem-specific calls to use Tcl pendants except thoser related to ADP and fastpath processing. This would induce no speed penalties to the request processing code. 2. Add fastpath.vfs flag which will, if set, use Tcl VFS path *after* exhausting all other possiblities (mmaping, direct access to file). This way one can override a page from the container file by providing the page on the filesystem. The vfs toggle will bet set to false by default. 3. Change ADP to use TclVFS in the same manner: first trying the file on the filesystem (as done now) and if it fails, using Tcl VFS wrappers. This way the VFS is a second-class citizen and would only be used as a fallback if the file cannot be otherwise found on the filesystem and if the VFS toggle has been flipped. Please give YES or NO (if NO, tell why) ---------------------------------------------------------------------- Comment By: Zoran Vasiljevic (vasiljevic) Date: 2005-05-16 13:43 Message: Logged In: YES user_id=95086 Oh yes. The packaging is what I'm (mostly) after. The only parts where mmap is used is fastpath.c. I do not know what/where is sendfile... So, effectively, the mmap has to be *enabled* to be used, right? Well, there is nothing wrong in leaving the mmap inplace. Actually, it should be also done in the way that Windows platform can use it (nees some wrapping but its easy done). But, it mmap is not enabled? Then the server uses standard open/read/close stuff from the OS. Now, what's wrong in using Tcl API equivalents of that? In that case, it is transparent where the file actually comes from, filesystem, zip/tarfile, etc... Do you think this could hit us performance-wise. I do not know. Maybe, but it's worth trying it out. Also, there are whole lotta places where the server uses OS calls to the filesystem which has nothing to do with serving pages (logfiles, access files, config files, etc...). These are not sensitive performance-wise and those places should/could be rewritten so we can bootstrap from zipfile if needed. Or be entirely wrapped in a startkit. What do you think? ---------------------------------------------------------------------- Comment By: Stephen Deasey (sdeasey) Date: 2005-05-16 13:30 Message: Logged In: YES user_id=87254 I'd be reluctant to let go of mmap and sendfile, considering our niche as a performace server. You can already use the vfs to read zip files etc., it's the single file packaging your after, right? ---------------------------------------------------------------------- Comment By: Zoran Vasiljevic (vasiljevic) Date: 2005-05-16 08:55 Message: Logged In: YES user_id=95086 The advantage is that you can for example, assemble all of the server distro in a starkit and distribute it as a wrapped application. Also, all sorts of filesystem wrappers (tar, zip, metakit, http, ...) are already implemeted in TclVFS so you can serve pages out of the tar/zip files directly, for example. No, mmap kind of things would be not possible since all would be going thru Tcl API. But, where is the mmap used? I believe only in fastpath and only if you explicitly enable it. And, only for Unix port. ---------------------------------------------------------------------- Comment By: Stephen Deasey (sdeasey) Date: 2005-05-16 01:25 Message: Logged In: YES user_id=87254 What would be the advantage of using the Tcl VFS? Would it be just as fast? Could we still use performance enhancemts such as mmap() and sendfile()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1202462&group_id=130646 |
|
From: SourceForge.net <no...@so...> - 2005-06-17 19:15:33
|
Feature Requests item #1202462, was opened at 2005-05-15 14:14 Message generated for change (Comment added) made by sdeasey You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1202462&group_id=130646 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: C-API Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zoran Vasiljevic (vasiljevic) Assigned to: Zoran Vasiljevic (vasiljevic) Summary: Rewrite to use Tcl VFS filesystem abstraction Initial Comment: We should really invest some time and rewrite all (most?) of the internal usages of open(), stat() (etc) so we can take advantage of Tcl virtual filesystem wappers. ---------------------------------------------------------------------- >Comment By: Stephen Deasey (sdeasey) Date: 2005-06-17 13:15 Message: Logged In: YES user_id=87254 Basically, YES. I don't think you need the vfs configuration flag. The check to see if mmap is enabled comes before the vfs flag in the fastpath code, so no matter what you set vfs to, it may be overidden by mmap. You should drop the vfs flag and make vfs the default if mmap is not enabled (as that is currently the only other option). i.e. also drop the fallback to normal open() etc. if vfs is not enabled. The original concern was that the file descriptor would not be available so that more advanced IO calls could be used, not that Tcl_VFSOpen() is noticably slower than open() etc. But you've shown how to deal with that, so I think just use Tcl VFS throughout, for simplicity. The same applies to the adp code, just use Tcl VFS. Any possible minor slowdown when accessing the file sytem should be hidden by the ADP memory cache anyway. So, the instruction for folks who want to use the Tcl VFS hooks to overide normal FS processing would be to make sure mmap (currently, plus any future optimisation) is turned off. ---------------------------------------------------------------------- Comment By: Zoran Vasiljevic (vasiljevic) Date: 2005-06-17 03:58 Message: Logged In: YES user_id=95086 This is how I plan to proceede on this topic. 1. Rewrite all filesystem-specific calls to use Tcl pendants except thoser related to ADP and fastpath processing. This would induce no speed penalties to the request processing code. 2. Add fastpath.vfs flag which will, if set, use Tcl VFS path *after* exhausting all other possiblities (mmaping, direct access to file). This way one can override a page from the container file by providing the page on the filesystem. The vfs toggle will bet set to false by default. 3. Change ADP to use TclVFS in the same manner: first trying the file on the filesystem (as done now) and if it fails, using Tcl VFS wrappers. This way the VFS is a second-class citizen and would only be used as a fallback if the file cannot be otherwise found on the filesystem and if the VFS toggle has been flipped. Please give YES or NO (if NO, tell why) ---------------------------------------------------------------------- Comment By: Zoran Vasiljevic (vasiljevic) Date: 2005-05-16 05:43 Message: Logged In: YES user_id=95086 Oh yes. The packaging is what I'm (mostly) after. The only parts where mmap is used is fastpath.c. I do not know what/where is sendfile... So, effectively, the mmap has to be *enabled* to be used, right? Well, there is nothing wrong in leaving the mmap inplace. Actually, it should be also done in the way that Windows platform can use it (nees some wrapping but its easy done). But, it mmap is not enabled? Then the server uses standard open/read/close stuff from the OS. Now, what's wrong in using Tcl API equivalents of that? In that case, it is transparent where the file actually comes from, filesystem, zip/tarfile, etc... Do you think this could hit us performance-wise. I do not know. Maybe, but it's worth trying it out. Also, there are whole lotta places where the server uses OS calls to the filesystem which has nothing to do with serving pages (logfiles, access files, config files, etc...). These are not sensitive performance-wise and those places should/could be rewritten so we can bootstrap from zipfile if needed. Or be entirely wrapped in a startkit. What do you think? ---------------------------------------------------------------------- Comment By: Stephen Deasey (sdeasey) Date: 2005-05-16 05:30 Message: Logged In: YES user_id=87254 I'd be reluctant to let go of mmap and sendfile, considering our niche as a performace server. You can already use the vfs to read zip files etc., it's the single file packaging your after, right? ---------------------------------------------------------------------- Comment By: Zoran Vasiljevic (vasiljevic) Date: 2005-05-16 00:55 Message: Logged In: YES user_id=95086 The advantage is that you can for example, assemble all of the server distro in a starkit and distribute it as a wrapped application. Also, all sorts of filesystem wrappers (tar, zip, metakit, http, ...) are already implemeted in TclVFS so you can serve pages out of the tar/zip files directly, for example. No, mmap kind of things would be not possible since all would be going thru Tcl API. But, where is the mmap used? I believe only in fastpath and only if you explicitly enable it. And, only for Unix port. ---------------------------------------------------------------------- Comment By: Stephen Deasey (sdeasey) Date: 2005-05-15 17:25 Message: Logged In: YES user_id=87254 What would be the advantage of using the Tcl VFS? Would it be just as fast? Could we still use performance enhancemts such as mmap() and sendfile()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1202462&group_id=130646 |
|
From: SourceForge.net <no...@so...> - 2005-06-17 09:58:46
|
Feature Requests item #1202462, was opened at 2005-05-15 22:14 Message generated for change (Comment added) made by vasiljevic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1202462&group_id=130646 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: C-API Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zoran Vasiljevic (vasiljevic) Assigned to: Zoran Vasiljevic (vasiljevic) Summary: Rewrite to use Tcl VFS filesystem abstraction Initial Comment: We should really invest some time and rewrite all (most?) of the internal usages of open(), stat() (etc) so we can take advantage of Tcl virtual filesystem wappers. ---------------------------------------------------------------------- >Comment By: Zoran Vasiljevic (vasiljevic) Date: 2005-06-17 11:58 Message: Logged In: YES user_id=95086 This is how I plan to proceede on this topic. 1. Rewrite all filesystem-specific calls to use Tcl pendants except thoser related to ADP and fastpath processing. This would induce no speed penalties to the request processing code. 2. Add fastpath.vfs flag which will, if set, use Tcl VFS path *after* exhausting all other possiblities (mmaping, direct access to file). This way one can override a page from the container file by providing the page on the filesystem. The vfs toggle will bet set to false by default. 3. Change ADP to use TclVFS in the same manner: first trying the file on the filesystem (as done now) and if it fails, using Tcl VFS wrappers. This way the VFS is a second-class citizen and would only be used as a fallback if the file cannot be otherwise found on the filesystem and if the VFS toggle has been flipped. Please give YES or NO (if NO, tell why) ---------------------------------------------------------------------- Comment By: Zoran Vasiljevic (vasiljevic) Date: 2005-05-16 13:43 Message: Logged In: YES user_id=95086 Oh yes. The packaging is what I'm (mostly) after. The only parts where mmap is used is fastpath.c. I do not know what/where is sendfile... So, effectively, the mmap has to be *enabled* to be used, right? Well, there is nothing wrong in leaving the mmap inplace. Actually, it should be also done in the way that Windows platform can use it (nees some wrapping but its easy done). But, it mmap is not enabled? Then the server uses standard open/read/close stuff from the OS. Now, what's wrong in using Tcl API equivalents of that? In that case, it is transparent where the file actually comes from, filesystem, zip/tarfile, etc... Do you think this could hit us performance-wise. I do not know. Maybe, but it's worth trying it out. Also, there are whole lotta places where the server uses OS calls to the filesystem which has nothing to do with serving pages (logfiles, access files, config files, etc...). These are not sensitive performance-wise and those places should/could be rewritten so we can bootstrap from zipfile if needed. Or be entirely wrapped in a startkit. What do you think? ---------------------------------------------------------------------- Comment By: Stephen Deasey (sdeasey) Date: 2005-05-16 13:30 Message: Logged In: YES user_id=87254 I'd be reluctant to let go of mmap and sendfile, considering our niche as a performace server. You can already use the vfs to read zip files etc., it's the single file packaging your after, right? ---------------------------------------------------------------------- Comment By: Zoran Vasiljevic (vasiljevic) Date: 2005-05-16 08:55 Message: Logged In: YES user_id=95086 The advantage is that you can for example, assemble all of the server distro in a starkit and distribute it as a wrapped application. Also, all sorts of filesystem wrappers (tar, zip, metakit, http, ...) are already implemeted in TclVFS so you can serve pages out of the tar/zip files directly, for example. No, mmap kind of things would be not possible since all would be going thru Tcl API. But, where is the mmap used? I believe only in fastpath and only if you explicitly enable it. And, only for Unix port. ---------------------------------------------------------------------- Comment By: Stephen Deasey (sdeasey) Date: 2005-05-16 01:25 Message: Logged In: YES user_id=87254 What would be the advantage of using the Tcl VFS? Would it be just as fast? Could we still use performance enhancemts such as mmap() and sendfile()? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1202462&group_id=130646 |
|
From: SourceForge.net <no...@so...> - 2005-06-16 18:34:08
|
Feature Requests item #1222107, was opened at 2005-06-16 20:15 Message generated for change (Comment added) made by vasiljevic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1222107&group_id=130646 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: C-API Group: None >Status: Closed >Resolution: Accepted Priority: 6 Submitted By: Zoran Vasiljevic (vasiljevic) Assigned to: Zoran Vasiljevic (vasiljevic) Summary: Remove redundant maxpost config option Initial Comment: The maxpost config option (per-virtual-server) is redundant and wrongly tested in driver.c. Since the real brake to DOS attacks is the maxinput (per socket-driver instance) we can safely drop this knob. It will make setup easier. People should use the maxinput option of the socket driver if they need to limit the accepted input beyond the default of 1MB per request. ---------------------------------------------------------------------- >Comment By: Zoran Vasiljevic (vasiljevic) Date: 2005-06-16 20:34 Message: Logged In: YES user_id=95086 Fixed in the current head branch. . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1222107&group_id=130646 |
|
From: SourceForge.net <no...@so...> - 2005-06-16 18:15:34
|
Feature Requests item #1222107, was opened at 2005-06-16 20:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1222107&group_id=130646 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: C-API Group: None Status: Open Resolution: None Priority: 6 Submitted By: Zoran Vasiljevic (vasiljevic) Assigned to: Zoran Vasiljevic (vasiljevic) Summary: Remove redundant maxpost config option Initial Comment: The maxpost config option (per-virtual-server) is redundant and wrongly tested in driver.c. Since the real brake to DOS attacks is the maxinput (per socket-driver instance) we can safely drop this knob. It will make setup easier. People should use the maxinput option of the socket driver if they need to limit the accepted input beyond the default of 1MB per request. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1222107&group_id=130646 |
|
From: SourceForge.net <no...@so...> - 2005-06-10 21:54:07
|
Feature Requests item #1215725, was opened at 2005-06-06 08:46 Message generated for change (Settings changed) made by sdeasey You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1215725&group_id=130646 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: C-API Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Stephen Deasey (sdeasey) Assigned to: Stephen Deasey (sdeasey) Summary: Stronger compile time error checking Initial Comment: GCC supports attributes with which you can do things like: int Ns_Foo(char *server) __attribute__((__nonnull__(1))); This says that arg 1 (the only arg) of Ns_Foo can never be a NULL pointer. This is checked at compile time, and a warning is issued if a NULL is found. The attached patch contains a new header file nscheck.h which would allow you to specify the above as: int Ns_Foo(char *server) NS_GNUC_NONNULL(1); This is only defined if the correct version of GCC is being used. There are wrappers for many of the useful attributes. The patch also contains the macro NS_RCSID() which is a simple wrapper around the boiler plate: static const char *RCSID = "..." found at the top of each file. It prevents the string from being optimised out of the binary and suppresses the annoying warning message that the variable is unused. I'll touch every *.c file to update to this new macro. ---------------------------------------------------------------------- Comment By: Zoran Vasiljevic (vasiljevic) Date: 2005-06-08 08:33 Message: Logged In: YES user_id=95086 Seems fine. Go ahead ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1215725&group_id=130646 |
|
From: SourceForge.net <no...@so...> - 2005-06-10 21:53:42
|
Feature Requests item #1215725, was opened at 2005-06-06 08:46 Message generated for change (Settings changed) made by sdeasey You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1215725&group_id=130646 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: C-API Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Stephen Deasey (sdeasey) Assigned to: Stephen Deasey (sdeasey) Summary: Stronger compile time error checking Initial Comment: GCC supports attributes with which you can do things like: int Ns_Foo(char *server) __attribute__((__nonnull__(1))); This says that arg 1 (the only arg) of Ns_Foo can never be a NULL pointer. This is checked at compile time, and a warning is issued if a NULL is found. The attached patch contains a new header file nscheck.h which would allow you to specify the above as: int Ns_Foo(char *server) NS_GNUC_NONNULL(1); This is only defined if the correct version of GCC is being used. There are wrappers for many of the useful attributes. The patch also contains the macro NS_RCSID() which is a simple wrapper around the boiler plate: static const char *RCSID = "..." found at the top of each file. It prevents the string from being optimised out of the binary and suppresses the annoying warning message that the variable is unused. I'll touch every *.c file to update to this new macro. ---------------------------------------------------------------------- Comment By: Zoran Vasiljevic (vasiljevic) Date: 2005-06-08 08:33 Message: Logged In: YES user_id=95086 Seems fine. Go ahead ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1215725&group_id=130646 |
|
From: SourceForge.net <no...@so...> - 2005-06-08 14:33:14
|
Feature Requests item #1215725, was opened at 2005-06-06 16:46 Message generated for change (Comment added) made by vasiljevic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1215725&group_id=130646 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: C-API Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephen Deasey (sdeasey) Assigned to: Stephen Deasey (sdeasey) Summary: Stronger compile time error checking Initial Comment: GCC supports attributes with which you can do things like: int Ns_Foo(char *server) __attribute__((__nonnull__(1))); This says that arg 1 (the only arg) of Ns_Foo can never be a NULL pointer. This is checked at compile time, and a warning is issued if a NULL is found. The attached patch contains a new header file nscheck.h which would allow you to specify the above as: int Ns_Foo(char *server) NS_GNUC_NONNULL(1); This is only defined if the correct version of GCC is being used. There are wrappers for many of the useful attributes. The patch also contains the macro NS_RCSID() which is a simple wrapper around the boiler plate: static const char *RCSID = "..." found at the top of each file. It prevents the string from being optimised out of the binary and suppresses the annoying warning message that the variable is unused. I'll touch every *.c file to update to this new macro. ---------------------------------------------------------------------- >Comment By: Zoran Vasiljevic (vasiljevic) Date: 2005-06-08 16:33 Message: Logged In: YES user_id=95086 Seems fine. Go ahead ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1215725&group_id=130646 |
|
From: SourceForge.net <no...@so...> - 2005-06-06 14:46:55
|
Feature Requests item #1215725, was opened at 2005-06-06 08:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1215725&group_id=130646 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: C-API Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephen Deasey (sdeasey) Assigned to: Stephen Deasey (sdeasey) Summary: Stronger compile time error checking Initial Comment: GCC supports attributes with which you can do things like: int Ns_Foo(char *server) __attribute__((__nonnull__(1))); This says that arg 1 (the only arg) of Ns_Foo can never be a NULL pointer. This is checked at compile time, and a warning is issued if a NULL is found. The attached patch contains a new header file nscheck.h which would allow you to specify the above as: int Ns_Foo(char *server) NS_GNUC_NONNULL(1); This is only defined if the correct version of GCC is being used. There are wrappers for many of the useful attributes. The patch also contains the macro NS_RCSID() which is a simple wrapper around the boiler plate: static const char *RCSID = "..." found at the top of each file. It prevents the string from being optimised out of the binary and suppresses the annoying warning message that the variable is unused. I'll touch every *.c file to update to this new macro. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1215725&group_id=130646 |
|
From: SourceForge.net <no...@so...> - 2005-05-28 03:07:38
|
Bugs item #1187635, was opened at 2005-04-21 14:25 Message generated for change (Settings changed) made by sdeasey You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719006&aid=1187635&group_id=130646 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: C-API Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Zoran Vasiljevic (vasiljevic) Assigned to: Zoran Vasiljevic (vasiljevic) Summary: timegm() usage not mt-safe Initial Comment: In httptime.c timegm() is used w/o protective locks. This call is not thread safe. Definitely not on Darwin. ---------------------------------------------------------------------- Comment By: Zoran Vasiljevic (vasiljevic) Date: 2005-04-21 14:33 Message: Logged In: YES user_id=95086 Fixed in HEAD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719006&aid=1187635&group_id=130646 |
