naviserver-devel — Developer discussion

Re: [naviserver-devel] UIO_MAXIOV

[Zoran V. <zv...@ar...>]

Am 20.02.2007 um 15:23 schrieb Zoran Vasiljevic:

> Hi!
>
> I haven't updated the sources for quite a long time!
> We don't compile on anything else but Linux :-(
>
> Anyways, the UIO_MAXIOV seems to be defined only for
> Linux. Neither Mac OSX nor Sun Solaris (not to mention
> the Windows) define such constant. By looking arround
> I see people can not find a peace of mind with it.
> It varies between 16 and 1024 on different platforms etc.
> I will be conservative and define that to 16 on all
> systems that have no UIO_MAXIOV unless somebody has a
> better idea.
>

Now, look at that.... Isn't that nice :-(

34 	#ifndef UIO_MAXIOV
35 	# if defined(__FreeBSD__) || defined(__APPLE__) || defined 
(__NetBSD__)
36 	/* FreeBSD 4.7 defines it in sys/uio.h only if _KERNEL is  
specified */
37 	#  define UIO_MAXIOV 1024
38 	# elif defined(__sgi)
39 	/* IRIX 6.5 has sysconf(_SC_IOV_MAX) which might return 512 or  
bigger */
40 	#  define UIO_MAXIOV 512
41 	# elif defined(__sun)
42 	/* Solaris (and SunOS?) defines IOV_MAX instead */
43 	#  ifndef IOV_MAX
44 	#   define UIO_MAXIOV 16
45 	#  else
46 	#   define UIO_MAXIOV IOV_MAX
47 	#  endif
48 	# elif defined(IOV_MAX)
49 	#  define UIO_MAXIOV IOV_MAX
50 	# else
51 	#  error UIO_MAXIOV nor IOV_MAX are defined
52 	# endif
53 	#endif
54 	

[naviserver-devel] UIO_MAXIOV

[Zoran V. <zv...@ar...>]

Hi!

I haven't updated the sources for quite a long time!
We don't compile on anything else but Linux :-(

Anyways, the UIO_MAXIOV seems to be defined only for
Linux. Neither Mac OSX nor Sun Solaris (not to mention
the Windows) define such constant. By looking arround
I see people can not find a peace of mind with it.
It varies between 16 and 1024 on different platforms etc.
I will be conservative and define that to 16 on all
systems that have no UIO_MAXIOV unless somebody has a
better idea.

Cheers
Zoran

Re: [naviserver-devel] NS Initialization (Was: ::xotcl::unknown)

[Bernd E. <eid...@we...>]

Zoran,

many thanks for your work! I replaced the given files, commented out 
the "_my_sourcefiles" proc and call (as I load the files by a separate 
loader), but this time via the ns_ictl replacement. 

Thanks!
Bernd.

[naviserver-devel] NS Initialization (Was: ::xotcl::unknown)

[Zoran V. <zv...@ar...>]

Am 16.02.2007 um 18:05 schrieb Bernd Eidenschink:

> Hm, looks like with the 4.99.1 Sourceforge release there is no  
> problem loading
> xotcl files and working with it.
>
> The same seems to fail, no matter what lazyloader setting is used,  
> with the
> current bin/init.tcl and/or nstrace.tcl.

I have looked into that part... (LONG!)

The trouble is the way how NS or AS are initialized.

Both (yes, we do still use that old arcane init stuff) are doing pretty
much complicated and error-prone stuff to get all the Tcl files sourced
and all the modules loaded.

The way how it works is (roughly):

   o. all tcl files are sourced
   o. introspective script is run to gather the state of the interp
   o. the script applied to every new Tcl interp

This is of course sub-optimal for any complex interp initialization.
Tcl (still) does not offer a capability to replicate a loaded interp.
There are several attempts to do so, but most of them are/were limited
in scope. Over the lifetime of AS project (including our own NS fork)
there have been several attempts to address this problem but no one was
really successful.

As of V4, there is a vehicle to do this right and that is: ns_ictl
(stands for "interpreter control"). You can use this to register  
callbacks
which are to be executed at interpreter creation, deletion, etc. This is
the most flexible way how one could/should tangle that (complex)  
problem.

Therefore I suggest we take complete different way for hanling XOTcl at
the interp start than we do now. Over the time we can rewrite the  
existing
code to use ns_ictl only, w/o fiddling with that home-brewn script  
synthesis.
This will simplify the things greatly.

The idea is to issue something like

     ns_ictl oninit {package require XOTcl}
     foreach file $xotcl_files {
         ns_ictl oninit {source $file)
     }

during server startup. The "xotcl_files" would hold list of
all *.xotcl files found in various places (in [ns_library shared]
and/or [ns_library private]).

I have written a trivial XOTcl loader (attached). Please note that
the nstrace.tcl (attached) is slightly modified to *exclude* processing
of xotcl namespace (I will have to check this into CVS but for the
meantime, please just put both files under /usr/local/ns/tcl or under
/usr/local/ns/modules/tcl directory).

How it works now is:

     xotcl.tcl issues ns_itcl oninit {package req XOTcl}
     then it collects all shared/private *.xotcl files
     for every file it does: ns_ictl "source $file"

This is MUCH simpler, works always and everybody can understand it.
It might be that this will introduce a small speed penalty when
creating an interpreter, but most modern computers are so fast that
you will not notice that in real life.

A word on lazy loading... this is MUCH more complicated stuff as it
requires special support from XOTcl in addition to the nstrace.tcl
code. Fortunately, there is a way to do that and we are using this
in our product. Unfortunately, I have no time at this moment to get
it done "right" for everybody to use. So, for the time being please
refrain from using lazy-loading of XOTcl.

If the attachments are filtered by the list handler please tell
me so I can put them somewhere for download.

Cheers,
Zoran

Re: [naviserver-devel] Anyway to disable Transfer-Encoding for /*.tcl pages?

[Michael A. C. <cle...@gm...>]

On 2/19/07, Vlad Seryakov <vl...@cr...> wrote:
> Try latest CVS version, it will work correctly now. Other solution to
> remove charset parameters in the ns/paramaters section, this way no
> encoding will be performed.

It works great, thanks!

Michael

[naviserver-devel] Eyeball before committing

[Stephen D. <sd...@gm...>]

On 2/19/07, Vlad Seryakov <ser...@us...> wrote:
>
> Update of /cvsroot/naviserver/naviserver/nsd
> In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv12140
>
> Modified Files:
>         driver.c
> Log Message:
> Ooops, wrong version of driver.c got into CVS, reverting to original
>
>
> *** driver.c    19 Feb 2007 20:17:40 -0000      1.84
> --- driver.c    19 Feb 2007 20:20:30 -0000      1.85
> ***************
> *** 65,68 ****
> --- 65,69 ----
>    * LoggingFlag mask values
>    */
> +
>   #define LOGGING_READTIMEOUT      (1<<0)
>   #define LOGGING_SERVERREJECT     (1<<1)


echo "diff -u" > ~/.cvsrc

$ cvs diff | diffstat
$ cvs diff | less

$ edit ChangeLog
$ cvs commit


:-)

Re: [naviserver-devel] Anyway to disable Transfer-Encoding for /*.tcl pages?

[Vlad S. <vl...@cr...>]

Try latest CVS version, it will work correctly now. Other solution to 
remove charset parameters in the ns/paramaters section, this way no 
encoding will be performed

Michael A. Cleverly wrote:
> Is there a way to disable using chunked encoding to reply to a
> particular request?
> 
> AFAICT (with enabletclpages on), any *.tcl page under the documentroot will
> have its content returned to the user with a Transfer-Encoding: chunked,
> regardless of whether the request is HTTP/0.9, HTTP/1.0 or HTTP/1.1.
> 
> For modern browsers this isn't an issue as they'll generally always make
> (and understand a response in) HTTP/1.1 requests. But for some clients
> (i.e., Lynx, wget, etc.) that don't expect an HTTP/1.1 encoded reply the
> transfer-encoding byte ranges end up being interpreted as part of the
> response body.
> 
> For example, I have the following one line script in
> $NSHOME/pages/hello.tcl:
> 
>     ns_return 200 text/plain "Hello World"
> 
> ## HTTP/1.1 request (expected result)
> michael@ned:/usr/local/ns/pages$ telnet localhost 80
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> GET /hello.tcl HTTP/1.1
> Host: localhost
> Connection: close
> 
> HTTP/1.1 200 OK
> MIME-Version: 1.0
> Accept-Ranges: bytes
> Date: Mon, 19 Feb 2007 19:06:01 GMT
> Server: NaviServer/4.99.2
> Content-Type: text/plain; charset=utf-8
> Transfer-Encoding: chunked
> Connection: close
> 
> b
> Hello World
> 0
> 
> Connection closed by foreign host.
> 
> ## HTTP/1.0 request (unexpected result)
> michael@ned:/usr/local/ns/pages$ telnet localhost 80
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> GET /hello.tcl HTTP/1.0
> Connection: close
> 
> HTTP/1.1 200 OK
> MIME-Version: 1.0
> Accept-Ranges: bytes
> Date: Mon, 19 Feb 2007 19:06:14 GMT
> Server: NaviServer/4.99.2
> Content-Type: text/plain; charset=utf-8
> Transfer-Encoding: chunked
> Connection: close
> 
> b
> Hello World
> 0
> 
> Connection closed by foreign host.
> 
> ## HTTP/0.9 request (unexpected result; do we need
> ## to even support HTTP/0.9 really?)
> michael@ned:/usr/local/ns/pages$ telnet localhost 80
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> GET /hello.tcl
> b
> Hello World
> 0
> 
> Connection closed by foreign host.
> 
> ## From Lynx (unexpected result)
> michael@ned:/usr/local/ns/pages$ lynx -dump http://localhost/hello.tcl
> b
> Hello World
> 0
> 
> (All of the above tested with Naviserver compiled from CVS HEAD as of Feb
> 7th, 2007 & Tcl 8.4.14 under Debian.)
> 
> Thanks,
> 
> Michael
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 


-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] Anyway to disable Transfer-Encoding for /*.tcl pages?

[Vlad S. <vl...@cr...>]

Good point, should not use chunked if not HTTP/1.1

i will take a look

Michael A. Cleverly wrote:
> Is there a way to disable using chunked encoding to reply to a
> particular request?
> 
> AFAICT (with enabletclpages on), any *.tcl page under the documentroot will
> have its content returned to the user with a Transfer-Encoding: chunked,
> regardless of whether the request is HTTP/0.9, HTTP/1.0 or HTTP/1.1.
> 
> For modern browsers this isn't an issue as they'll generally always make
> (and understand a response in) HTTP/1.1 requests. But for some clients
> (i.e., Lynx, wget, etc.) that don't expect an HTTP/1.1 encoded reply the
> transfer-encoding byte ranges end up being interpreted as part of the
> response body.
> 
> For example, I have the following one line script in
> $NSHOME/pages/hello.tcl:
> 
>     ns_return 200 text/plain "Hello World"
> 
> ## HTTP/1.1 request (expected result)
> michael@ned:/usr/local/ns/pages$ telnet localhost 80
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> GET /hello.tcl HTTP/1.1
> Host: localhost
> Connection: close
> 
> HTTP/1.1 200 OK
> MIME-Version: 1.0
> Accept-Ranges: bytes
> Date: Mon, 19 Feb 2007 19:06:01 GMT
> Server: NaviServer/4.99.2
> Content-Type: text/plain; charset=utf-8
> Transfer-Encoding: chunked
> Connection: close
> 
> b
> Hello World
> 0
> 
> Connection closed by foreign host.
> 
> ## HTTP/1.0 request (unexpected result)
> michael@ned:/usr/local/ns/pages$ telnet localhost 80
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> GET /hello.tcl HTTP/1.0
> Connection: close
> 
> HTTP/1.1 200 OK
> MIME-Version: 1.0
> Accept-Ranges: bytes
> Date: Mon, 19 Feb 2007 19:06:14 GMT
> Server: NaviServer/4.99.2
> Content-Type: text/plain; charset=utf-8
> Transfer-Encoding: chunked
> Connection: close
> 
> b
> Hello World
> 0
> 
> Connection closed by foreign host.
> 
> ## HTTP/0.9 request (unexpected result; do we need
> ## to even support HTTP/0.9 really?)
> michael@ned:/usr/local/ns/pages$ telnet localhost 80
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> GET /hello.tcl
> b
> Hello World
> 0
> 
> Connection closed by foreign host.
> 
> ## From Lynx (unexpected result)
> michael@ned:/usr/local/ns/pages$ lynx -dump http://localhost/hello.tcl
> b
> Hello World
> 0
> 
> (All of the above tested with Naviserver compiled from CVS HEAD as of Feb
> 7th, 2007 & Tcl 8.4.14 under Debian.)
> 
> Thanks,
> 
> Michael
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 


-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

[naviserver-devel] Anyway to disable Transfer-Encoding for /*.tcl pages?

[Michael A. C. <cle...@gm...>]

Is there a way to disable using chunked encoding to reply to a
particular request?

AFAICT (with enabletclpages on), any *.tcl page under the documentroot will
have its content returned to the user with a Transfer-Encoding: chunked,
regardless of whether the request is HTTP/0.9, HTTP/1.0 or HTTP/1.1.

For modern browsers this isn't an issue as they'll generally always make
(and understand a response in) HTTP/1.1 requests. But for some clients
(i.e., Lynx, wget, etc.) that don't expect an HTTP/1.1 encoded reply the
transfer-encoding byte ranges end up being interpreted as part of the
response body.

For example, I have the following one line script in
$NSHOME/pages/hello.tcl:

    ns_return 200 text/plain "Hello World"

## HTTP/1.1 request (expected result)
michael@ned:/usr/local/ns/pages$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /hello.tcl HTTP/1.1
Host: localhost
Connection: close

HTTP/1.1 200 OK
MIME-Version: 1.0
Accept-Ranges: bytes
Date: Mon, 19 Feb 2007 19:06:01 GMT
Server: NaviServer/4.99.2
Content-Type: text/plain; charset=utf-8
Transfer-Encoding: chunked
Connection: close

b
Hello World
0

Connection closed by foreign host.

## HTTP/1.0 request (unexpected result)
michael@ned:/usr/local/ns/pages$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /hello.tcl HTTP/1.0
Connection: close

HTTP/1.1 200 OK
MIME-Version: 1.0
Accept-Ranges: bytes
Date: Mon, 19 Feb 2007 19:06:14 GMT
Server: NaviServer/4.99.2
Content-Type: text/plain; charset=utf-8
Transfer-Encoding: chunked
Connection: close

b
Hello World
0

Connection closed by foreign host.

## HTTP/0.9 request (unexpected result; do we need
## to even support HTTP/0.9 really?)
michael@ned:/usr/local/ns/pages$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /hello.tcl
b
Hello World
0

Connection closed by foreign host.

## From Lynx (unexpected result)
michael@ned:/usr/local/ns/pages$ lynx -dump http://localhost/hello.tcl
b
Hello World
0

(All of the above tested with Naviserver compiled from CVS HEAD as of Feb
7th, 2007 & Tcl 8.4.14 under Debian.)

Thanks,

Michael

Re: [naviserver-devel] OpenBSD/sparc64: driver blocks on a new connection if acceptsize > 1

[Michael A. C. <cle...@gm...>]

On 2/10/07, Stephen Deasey <sd...@gm...> wrote:
> You could try compiling the kernel with support for RTHREADS enabled.
>
> Then compile the rthreads library in /usr/src/lib/librthread
>
> Then link against it for 1-1 user-kernel threads.

Rather than recompiling OpenBSD I decided to start fresh and installed
Debian/sparc instead.  I can compile CVS HEAD and it serves requests
fine.  The control port does not ever respond but I don't really need
it for the project I'm working on so I just don't load nscp.so at the
moment.  Sometime I might go back and poke & try and figure out why...

> Naviserver user threads sometimes explicitly to avoid blocking other
> threads.  With a user-level thread library any blocking thread will
> block the whole process, so the extra threads will just be overhead.
>
> A plain old single process server might perform better. (or multiprocess apache)

But then I'd have to do without the ns_* Tcl API.  :)

Thanks,

Michael

Re: [naviserver-devel] ::xotcl::unknown

[Zoran V. <zv...@ar...>]

Am 16.02.2007 um 18:08 schrieb Zoran Vasiljevic:

> I will look into that tomorrow. Please tell me how do you load Xotcl
> in the running server.

I'm sorry but I didn't come to it over the weekend.
I hope today is a better day...

Cheers
Zoran

Re: [naviserver-devel] ::xotcl::unknown

[Bernd E. <eid...@we...>]

>> Hm, looks like with the 4.99.1 Sourceforge release there is no
>> problem loading
>> xotcl files and working with it.
>>
>> The same seems to fail, no matter what lazyloader setting is used,  
>> with the
>> current bin/init.tcl and/or nstrace.tcl.

> I will look into that tomorrow. Please tell me how do you load Xotcl
> in the running server.

Hi Zoran, I guess nothing special, I have two directories
tcl_shared/
tcl_private/
The usual .tcl files are loaded from within tcl_shared/; also the
aol-xotcl.tcl (I renamed to xotcl.tcl :-)).
After that a "loader" file of my own in tcl_private/ sources a lot of
.tcl and .xotcl files located in other directories.

So, in the aol-xotcl.tcl the last three lines with the
ns_eval {
...
}
are commented out, as my own loader file loads all the .xotcl files.

( Btw.: it appears that if lazyloader=true the nstrace.tcl is loaded
twice? Sourced by bin/init.tcl and then during the
load-every-file-in-the-shared-lib-dir? )

Bernd.

Re: [naviserver-devel] ::xotcl::unknown

[Zoran V. <zv...@ar...>]

Am 16.02.2007 um 18:05 schrieb Bernd Eidenschink:

> Hm, looks like with the 4.99.1 Sourceforge release there is no  
> problem loading
> xotcl files and working with it.
>
> The same seems to fail, no matter what lazyloader setting is used,  
> with the
> current bin/init.tcl and/or nstrace.tcl.

I will look into that tomorrow. Please tell me how do you load Xotcl
in the running server.

Cheers
Zoran

Re: [naviserver-devel] ::xotcl::unknown

[Bernd E. <eid...@we...>]

Hm, looks like with the 4.99.1 Sourceforge release there is no problem loading 
xotcl files and working with it.

The same seems to fail, no matter what lazyloader setting is used, with the 
current bin/init.tcl and/or nstrace.tcl.

Bernd.

Re: [naviserver-devel] ::xotcl::unknown

[Bernd E. <eid...@we...>]

The _ns_savenamespaces{} proc included in aol-xotcl.tcl that overloaded the 
proc in the aolserver init script is not used in the naviserver startup 
process, as this proc does not exist there.

Is there a patch needed somewhere in the bin/init.tcl resp. nstrace.tcl to 
accomplish the same behaviour?


-------------------------------------------------------------

#
# Overload procedure defined in bin/init.tcl.
# It is now XOTcl-savvy in how it treats some
# special namespaces.
#

proc _ns_savenamespaces {} {
...
}

Re: [naviserver-devel] ::xotcl::unknown

[Bernd E. <eid...@we...>]

> Interesting! I will have to check this. I believe it is
> there by mistake. That is, if you do not load xotcl package.
> Do you?

I do! But maybe the problem is elsewhere.

What I did here is: In the shared Tcl directory I have the aol-xotcl.tcl that 
loads the XOTcl package (fine, as the
ns_log notice "XOTcl version $::xotcl::version$::xotcl::patchlevel loaded"
message appears in the serverlog).

I commented out the last three lines in that file:
#ns_eval {
#  _my_sourcefiles [ns_library shared] [ns_library private]
#}

as I have my own "loader" in the private Tcl directory that loads .tcl 
and .xotcl files in other, separate directories, as part of the startup.

As far as I can see, all  the different .tcl and .xotcl files are sourced and 
loaded.

With lazyloader=false, the error appears immediately

>[-main-] Error: invalid command name "::xotcl::unknown"
>invalid command name "::xotcl::unknown"
>   while executing
>"namespace origin $pn"
>    (procedure "_serializensp" line 12)
>    invoked from within
>"_serializensp $n"
>    (procedure "nstrace::statescript" line 36)
>    invoked from within
>"nstrace::statescript"
>   invoked from within

with lazyloader=true, as long as no XOTcl code is run, no error. So it might 
in fact be some namespace related problem.

Bernd.

Re: [naviserver-devel] ::xotcl::unknown

[Zoran V. <zv...@ar...>]

Am 15.02.2007 um 18:47 schrieb Bernd Eidenschink:

>
> What might cause the problem if I run into the error below, when  
> starting the
> server in lazyloader=false mode:
>
> ===========================================
>
>  Error: invalid command name "::xotcl::unknown"
> invalid command name "::xotcl::unknown"
>     while executing
> "namespace origin $pn"
>     (procedure "_serializensp" line 12)
>     invoked from within
> "_serializensp $n"
>     (procedure "nstrace::statescript" line 36)
>     invoked from within
> "nstrace::statescript"
>     invoked from within
> "if {$use_trace_inits} {
>

Interesting! I will have to check this. I believe it is
there by mistake. That is, if you do not load xotcl package.
Do you?

Cheers
Zoran

[naviserver-devel] ::xotcl::unknown

[Bernd E. <eid...@we...>]

Hi Folks!

What might cause the problem if I run into the error below, when starting the 
server in lazyloader=false mode:

===========================================

 Error: invalid command name "::xotcl::unknown"
invalid command name "::xotcl::unknown"
    while executing
"namespace origin $pn"
    (procedure "_serializensp" line 12)
    invoked from within
"_serializensp $n"
    (procedure "nstrace::statescript" line 36)
    invoked from within
"nstrace::statescript"
    invoked from within
"if {$use_trace_inits} {


===========================================

Thanks for any hint,

Bernd.

Re: [naviserver-devel] OpenBSD/sparc64: driver blocks on a new connection if acceptsize > 1

[Stephen D. <sd...@gm...>]

On 2/10/07, Stephen Deasey <sd...@gm...> wrote:
> On 2/10/07, Michael A. Cleverly <cle...@gm...> wrote:
> > My adventures (with CVS HEAD) on OpenBSD/sparc64 continue.
> >
> > Unless I set:
> >
> >     ns_section      "ns/server/${servername}/module/nssock"
> >     ns_param       acceptsize          1
> >
> > in my conf file then incoming an HTTP request never get serviced
> > promptly; I can't connect to the nscp control port, and I can't hit
> > CTRL-C to end the (foreground) nsd process.
>
>
> The control port uses the nsd/sockcallback.c mechanism to handle new
> connections, which runs in a seperate thread.  So even if the driver
> thread was blocked, I would not expect that to prevent you from
> logging in via the control port.
>
> What threading library does OpenBSD have these days?  I thought they
> had an option for real, 1-1 user-kernel threads.
>
> Maybe we need to link to the correct thread library?
>
> Still, the driver thread shouldn't be blocking...
>


You could try compiling the kernel with support for RTHREADS enabled.

Then compile the rthreads library in /usr/src/lib/librthread

Then link against it for 1-1 user-kernel threads.


Naviserver user threads sometimes explicitly to avoid blocking other
threads.  With a user-level thread library any blocking thread will
block the whole process, so the extra threads will just be overhead.

A plain old single process server might perform better. (or multiprocess apache)

Re: [naviserver-devel] OpenBSD/sparc64: driver blocks on a new connection if acceptsize > 1

[Stephen D. <sd...@gm...>]

On 2/10/07, Michael A. Cleverly <cle...@gm...> wrote:
> My adventures (with CVS HEAD) on OpenBSD/sparc64 continue.
>
> Unless I set:
>
>     ns_section      "ns/server/${servername}/module/nssock"
>     ns_param       acceptsize          1
>
> in my conf file then incoming an HTTP request never get serviced
> promptly; I can't connect to the nscp control port, and I can't hit
> CTRL-C to end the (foreground) nsd process.
>
> If I set ns_param acceptsize to 2 then the first connection "hangs",
> when a second one is made both are processed immediately.
>
> The default acceptsize is equal to the backlog setting, which defaults
> to 256.  I strongly suspect (but haven't had the patience to confirm)
> that with no acceptsize setting I'd have to have 256 active HTTP
> connections before any would be processed at all.
>
> I've sprinkled driver.c, binder.c, and sock.c with caveman debugging
> Ns_Log() calls and it appears to block in the while loop attempting to
> accept more when calling the final check of the four checks [in
> DriverThread() in driver.c at line 1272]:
>
>      (sockPtr = SockAccept(drvPtr)) != NULL
>
> which seems to end up waiting  [in SockAccept() in driver.c at line 1635-6] on:
>
>         sockPtr->sock = Ns_SockAccept(drvPtr->sock,
>                                       (struct sockaddr *) &sockPtr->sa, &slen);
>
> which in turn waits [in Ns_SockAccept() in sock.c at line 420] on:
>
>     sock = accept(lsock, saPtr, (socklen_t *) lenPtr);
>
> which makes me think that the listening socket must not be set in
> non-blocking mode(?).


You could try adding a call to ns_sockioctl() to get the FIONBIO
status of the socket and dump to the log, just to confirm that it
really is set.

It should be -- it works on your other platforms.

Looks like an openbsd-on-sparc bug?

* Either the call to Ns_SetNonBlocking() in driver.c:NsStartDrivers()
is not taking effect
* or the non-blocking status is being dropped after the first call to accept()
* or non-blocking status is being ignored entirely for acept() on
listening sockets. It works the first time because there really is a
connection waiting.



> Suggestions? The same behavior does not occur on OpenBSD 3.8/macppc or
> OpenBSD 3.9/amd64. (Everything works "out-of-the-box" as expected.)
>
> Michael
>

Re: [naviserver-devel] OpenBSD/sparc64: driver blocks on a new connection if acceptsize > 1

[Vlad S. <vl...@cr...>]

Can it be that if accept is called when there is no incoming request 
something screwed up in the process so subsequent accepts even in other 
threads do not work?

Looks like OpenBSD may not allow to call extra accept

Michael A. Cleverly wrote:
> My adventures (with CVS HEAD) on OpenBSD/sparc64 continue.
> 
> Unless I set:
> 
>     ns_section      "ns/server/${servername}/module/nssock"
>     ns_param       acceptsize          1
> 
> in my conf file then incoming an HTTP request never get serviced
> promptly; I can't connect to the nscp control port, and I can't hit
> CTRL-C to end the (foreground) nsd process.
> 
> If I set ns_param acceptsize to 2 then the first connection "hangs",
> when a second one is made both are processed immediately.
> 
> The default acceptsize is equal to the backlog setting, which defaults
> to 256.  I strongly suspect (but haven't had the patience to confirm)
> that with no acceptsize setting I'd have to have 256 active HTTP
> connections before any would be processed at all.
> 
> I've sprinkled driver.c, binder.c, and sock.c with caveman debugging
> Ns_Log() calls and it appears to block in the while loop attempting to
> accept more when calling the final check of the four checks [in
> DriverThread() in driver.c at line 1272]:
> 
>      (sockPtr = SockAccept(drvPtr)) != NULL
> 
> which seems to end up waiting  [in SockAccept() in driver.c at line 1635-6] on:
> 
>         sockPtr->sock = Ns_SockAccept(drvPtr->sock,
>                                       (struct sockaddr *) &sockPtr->sa, &slen);
> 
> which in turn waits [in Ns_SockAccept() in sock.c at line 420] on:
> 
>     sock = accept(lsock, saPtr, (socklen_t *) lenPtr);
> 
> which makes me think that the listening socket must not be set in
> non-blocking mode(?).
> 
> Suggestions? The same behavior does not occur on OpenBSD 3.8/macppc or
> OpenBSD 3.9/amd64. (Everything works "out-of-the-box" as expected.)
> 
> Michael
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 


-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] OpenBSD/sparc64: driver blocks on a new connection if acceptsize > 1

[Stephen D. <sd...@gm...>]

On 2/10/07, Michael A. Cleverly <cle...@gm...> wrote:
> My adventures (with CVS HEAD) on OpenBSD/sparc64 continue.
>
> Unless I set:
>
>     ns_section      "ns/server/${servername}/module/nssock"
>     ns_param       acceptsize          1
>
> in my conf file then incoming an HTTP request never get serviced
> promptly; I can't connect to the nscp control port, and I can't hit
> CTRL-C to end the (foreground) nsd process.


The control port uses the nsd/sockcallback.c mechanism to handle new
connections, which runs in a seperate thread.  So even if the driver
thread was blocked, I would not expect that to prevent you from
logging in via the control port.

What threading library does OpenBSD have these days?  I thought they
had an option for real, 1-1 user-kernel threads.

Maybe we need to link to the correct thread library?

Still, the driver thread shouldn't be blocking...


> If I set ns_param acceptsize to 2 then the first connection "hangs",
> when a second one is made both are processed immediately.
>
> The default acceptsize is equal to the backlog setting, which defaults
> to 256.  I strongly suspect (but haven't had the patience to confirm)
> that with no acceptsize setting I'd have to have 256 active HTTP
> connections before any would be processed at all.
>
> I've sprinkled driver.c, binder.c, and sock.c with caveman debugging
> Ns_Log() calls and it appears to block in the while loop attempting to
> accept more when calling the final check of the four checks [in
> DriverThread() in driver.c at line 1272]:
>
>      (sockPtr = SockAccept(drvPtr)) != NULL
>
> which seems to end up waiting  [in SockAccept() in driver.c at line 1635-6] on:
>
>         sockPtr->sock = Ns_SockAccept(drvPtr->sock,
>                                       (struct sockaddr *) &sockPtr->sa, &slen);
>
> which in turn waits [in Ns_SockAccept() in sock.c at line 420] on:
>
>     sock = accept(lsock, saPtr, (socklen_t *) lenPtr);
>
> which makes me think that the listening socket must not be set in
> non-blocking mode(?).
>
> Suggestions? The same behavior does not occur on OpenBSD 3.8/macppc or
> OpenBSD 3.9/amd64. (Everything works "out-of-the-box" as expected.)
>
> Michael
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>

Re: [naviserver-devel] OpenBSD/sparc64: driver blocks on a new connection if acceptsize > 1

[Michael A. C. <cle...@gm...>]

On 2/10/07, Michael A. Cleverly <cle...@gm...> wrote:
> My adventures (with CVS HEAD) on OpenBSD/sparc64 continue.
>
> Unless I set:
>
>     ns_section      "ns/server/${servername}/module/nssock"
>     ns_param       acceptsize          1
>
> in my conf file then incoming an HTTP request never get serviced
> promptly; I can't connect to the nscp control port, and I can't hit
> CTRL-C to end the (foreground) nsd process.
>
> If I set ns_param acceptsize to 2 then the first connection "hangs",
> when a second one is made both are processed immediately.

Another data point: NaviServer 4.99.1 behaves as expected and does not
exhibit this behavior on sparc64.  [Although that follows from it not
knowing about acceptsize... :-/]

Michael

[naviserver-devel] OpenBSD/sparc64: driver blocks on a new connection if acceptsize > 1

[Michael A. C. <cle...@gm...>]

My adventures (with CVS HEAD) on OpenBSD/sparc64 continue.

Unless I set:

    ns_section      "ns/server/${servername}/module/nssock"
    ns_param       acceptsize          1

in my conf file then incoming an HTTP request never get serviced
promptly; I can't connect to the nscp control port, and I can't hit
CTRL-C to end the (foreground) nsd process.

If I set ns_param acceptsize to 2 then the first connection "hangs",
when a second one is made both are processed immediately.

The default acceptsize is equal to the backlog setting, which defaults
to 256.  I strongly suspect (but haven't had the patience to confirm)
that with no acceptsize setting I'd have to have 256 active HTTP
connections before any would be processed at all.

I've sprinkled driver.c, binder.c, and sock.c with caveman debugging
Ns_Log() calls and it appears to block in the while loop attempting to
accept more when calling the final check of the four checks [in
DriverThread() in driver.c at line 1272]:

     (sockPtr = SockAccept(drvPtr)) != NULL

which seems to end up waiting  [in SockAccept() in driver.c at line 1635-6] on:

        sockPtr->sock = Ns_SockAccept(drvPtr->sock,
                                      (struct sockaddr *) &sockPtr->sa, &slen);

which in turn waits [in Ns_SockAccept() in sock.c at line 420] on:

    sock = accept(lsock, saPtr, (socklen_t *) lenPtr);

which makes me think that the listening socket must not be set in
non-blocking mode(?).

Suggestions? The same behavior does not occur on OpenBSD 3.8/macppc or
OpenBSD 3.9/amd64. (Everything works "out-of-the-box" as expected.)

Michael

Re: [naviserver-devel] [ns_conn peeraddr] always = 0.0.0.0 on OpenBSD 4.0/sparc64?

[Michael A. C. <cle...@gm...>]

On 2/7/07, Vlad Seryakov <vl...@cr...> wrote:
> I updated configure.in in the CVS, can you run autogen.sh on CVS version
> and see if it will detect it right.

it does:

checking for inet_ntop... yes

Thanks for all your help.

Michael