naviserver-devel — Developer discussion

Re: [naviserver-devel] Ns_ConnFlushHeaders() deprecated: why?

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

On Tue, May 4, 2010 at 4:50 PM, Vasiljevic Zoran <zv...@ar...> wrote:
> Hi all!
>
> Tcl_WideInt
> Ns_ConnFlushHeaders(Ns_Conn *conn, int status)
> {
>     Conn *connPtr = (Conn *) conn;
>
>     Ns_ConnSetResponseStatus(conn, status);
>     Ns_ConnWriteData(conn, NULL, 0, 0);
>
>     return connPtr->nContentSent;
> }
>
> This function is set as deprecated. It returns number of bytes sent.
> I cannot see that connPtr->nContentSent is exposed from outside
> so how am I to obtain the original Ns_ConnFlushHeaders functionality
> w/o accessing internal connection state?


Flushing headers is discouraged because it isn't needed for HTTP, it's
slow, and often extra headers need to be added depending on which
Write* calls you use.

I guess you could give access to nContentSent in a new public API.
What are you using it for? How are you writing the data?

[naviserver-devel] Ns_ConnWriteData needs Ns_ConnFlushData ?

[Vasiljevic Z. <zv...@ar...>]

Hi!

Quite often I see:

    Ns_ConnWriteData(conn, NULL, 0, 0);

This is OK but not very readable. Can we add something like

    Ns_ConnFlushData(conn, flags)

convenience wrapper that would supply the NULL buffer and
zero bytes to the Ns_ConnWriteData() ?

This would add zero functionality but would make the
programmers intention more clear.

Cheers,
Zoran

[naviserver-devel] Ns_ConnFlushHeaders() deprecated: why?

[Vasiljevic Z. <zv...@ar...>]

Hi all!

Tcl_WideInt
Ns_ConnFlushHeaders(Ns_Conn *conn, int status)
{
     Conn *connPtr = (Conn *) conn;

     Ns_ConnSetResponseStatus(conn, status);
     Ns_ConnWriteData(conn, NULL, 0, 0);

     return connPtr->nContentSent;
}

This function is set as deprecated. It returns number of bytes sent.
I cannot see that connPtr->nContentSent is exposed from outside
so how am I to obtain the original Ns_ConnFlushHeaders functionality
w/o accessing internal connection state?

Cheers
Zoran

Re: [naviserver-devel] driver changes, please check

[Gustaf N. <ne...@wu...>]

Am 12.04.10 15:10, schrieb Stephen Deasey:
> You are going to have to merge the two heads with 'hg merge' and then
> push that changeset. See: hg help merge.
>    
many thanks! should be fine now.
-gustaf

Re: [naviserver-devel] driver changes, please check

[Gustaf N. <ne...@wu...>]

Am 12.04.10 15:18, schrieb Stephen Deasey:
> How about implementing chunked uploading?  It is a requirement of the
> HTTP 1.1 spec.
>    
i have implemented a version of this and committed and pushed it to the tip.

Provide Chunked Encoding support for incoming requests
   * Shortcomings:
      a) for chunked encodings, spooling to files is turned off (since 
decoding happens in memory)
      b) chunked encodings still require X-Expected-Entity-Length to 
terminate reliably

Checking for eof would be the best for (b).

-gustaf neumann

Re: [naviserver-devel] commit/naviserver: gustafn: - Fix to prevent multiple DriverAccepts on the same socket. The original coded relied on the fact that later accepts

[Gustaf N. <ne...@wu...>]

Am 12.04.10 18:30, schrieb Stephen Deasey:
> Actually this doesn't make any sense and shows how long it's been
> since I've touched any C.
>    

i haven't found any manpage where accepts results different errors than -1.

>> But, i got that sucker: In the following ioctl (and others
>> maybe as well) the "long" is wrong, since linux expects
>> there an int.  That's why we see the problem with 64bit
>> machines and on bsd!
>>      
> Well spotted.
>    
>> Does anyone know, how to figure out, on which platforms
>> the long is wanted? The majority seems to be "int".
>>      
>
> Not sure. Just go with int? How many people are running on MKS or Amiga?
>    
replaced 2 occurrences of the problem with int
and undid the first fix.

Best regards
-gustaf neumann

Re: [naviserver-devel] commit/naviserver: gustafn: - Fix to prevent multiple DriverAccepts on the same socket. The original coded relied on the fact that later accepts

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

On Mon, Apr 12, 2010 at 3:58 PM, Gustaf Neumann <ne...@wu...> wrote:
>
> Cool, good guess, but it did not help - but the proposed
> change should go into the repository.


Actually this doesn't make any sense and shows how long it's been
since I've touched any C.


> But, i got that sucker: In the following ioctl (and others
> maybe as well) the "long" is wrong, since linux expects
> there an int.  That's why we see the problem with 64bit
> machines and on bsd!


Well spotted.


> Does anyone know, how to figure out, on which platforms
> the long is wanted? The majority seems to be "int".


Not sure. Just go with int? How many people are running on MKS or Amiga?

Re: [naviserver-devel] commit/naviserver: gustafn: - Fix to prevent multiple DriverAccepts on the same socket. The original coded relied on the fact that later accepts

[Gustaf N. <ne...@wu...>]

Cool, good guess, but it did not help - but the proposed
change should go into the repository.

Not surpisingly, the hang happens only when (acceptsize > 1) ....

But, i got that sucker: In the following ioctl (and others
maybe as well) the "long" is wrong, since linux expects
there an int.  That's why we see the problem with 64bit
machines and on bsd!

========================================
int
Ns_SockSetNonBlocking(SOCKET sock)
{
     unsigned long nb = 1;
     if (ns_sockioctl(sock, FIONBIO, &nb) == -1) {
         return NS_ERROR;
     }
     return NS_OK;
}
========================================

Interestingly OpenBSD and linux

    http://www.rootr.net/man/man/ioctl/2
    http://linux.die.net/man/2/ioctl_list

list the type as "int",
while e.g. mks wants a "long"

    http://www.mkssoftware.com/docs/man5/sockets.5.asp

Does anyone know, how to figure out, on which platforms
the long is wanted? The majority seems to be "int".

-gustaf

Am 12.04.10 16:03, schrieb Stephen Deasey:
> On Mon, Apr 12, 2010 at 2:33 PM, Gustaf Neumann<ne...@wu...>  wrote:
>    
>> Without the patch naviserver hangs (blocks) on that machine already
>> at the first or second request.
>>      
>
> This should never happen as the listen socket is set to non-blocking mode, here:
>
>    http://bitbucket.org/naviserver/naviserver/src/tip/nssock/nssock.c#cl-131
>
> nssock.c:Accept() calls nsd/sock.c:Ns_SockAccept() which calls
> accept(2), who's man page says:
>
>      If no pending connections are present on the queue, and the socket
> is not marked
>      as non-blocking, accept() blocks the caller until a connection is
> present.  If the socket
>      is marked non-blocking and no pending connections are present on
> the queue, accept()
>      fails with the error EAGAIN or EWOULDBLOCK.
>
> In which case, Ns_SockAccept looks wrong:
>
> SOCKET
> Ns_SockAccept(SOCKET lsock, struct sockaddr *saPtr, int *lenPtr)
> {
>      SOCKET sock;
>
>      sock = accept(lsock, saPtr, (socklen_t *) lenPtr);
>
>      if (sock != INVALID_SOCKET) {
>          sock = SockSetup(sock);
>      }
>
>      return sock;
> }
>
>
> Shouldn't this be something more like:
>
>      if (sock>  -1) {
>          sock = SockSetup(sock);
>      }
>
> as INVALID_SOCKET is -1 but there is more than one possible error state?
>
> (I haven't tried this...)
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>    


-- 
Univ.Prof. Dr. Gustaf Neumann
Institute of Information Systems and New Media
WU Vienna
Augasse 2-6, A-1090 Vienna, AUSTRIA

Re: [naviserver-devel] commit/naviserver: gustafn: - Fix to prevent multiple DriverAccepts on the same socket. The original coded relied on the fact that later accepts

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

On Mon, Apr 12, 2010 at 2:33 PM, Gustaf Neumann <ne...@wu...> wrote:
>
> Without the patch naviserver hangs (blocks) on that machine already
> at the first or second request.


This should never happen as the listen socket is set to non-blocking mode, here:

  http://bitbucket.org/naviserver/naviserver/src/tip/nssock/nssock.c#cl-131

nssock.c:Accept() calls nsd/sock.c:Ns_SockAccept() which calls
accept(2), who's man page says:

    If no pending connections are present on the queue, and the socket
is not marked
    as non-blocking, accept() blocks the caller until a connection is
present.  If the socket
    is marked non-blocking and no pending connections are present on
the queue, accept()
    fails with the error EAGAIN or EWOULDBLOCK.

In which case, Ns_SockAccept looks wrong:

SOCKET
Ns_SockAccept(SOCKET lsock, struct sockaddr *saPtr, int *lenPtr)
{
    SOCKET sock;

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

    if (sock != INVALID_SOCKET) {
        sock = SockSetup(sock);
    }

    return sock;
}


Shouldn't this be something more like:

    if (sock > -1) {
        sock = SockSetup(sock);
    }

as INVALID_SOCKET is -1 but there is more than one possible error state?

(I haven't tried this...)

Re: [naviserver-devel] commit/naviserver: gustafn: - Fix to prevent multiple DriverAccepts on the same socket. The original coded relied on the fact that later accepts

[Gustaf N. <ne...@wu...>]

I see, this is the intention. Without the patch naviserver
hangs (blocks) on that machine already at the first or second request.

Teh problems seems to be already around for a while, strangely on 64 bit 
machines:
http://www.mail-archive.com/nav...@li.../msg02244.html

We can try varying the acceptsize to see what happens....

-gustaf neumann

Am 12.04.10 14:52, schrieb Stephen Deasey:
> On Sun, Apr 11, 2010 at 4:16 PM,<com...@bi...>  wrote:
>    
>> changeset: 2575:3963e46562e8
>> user: Gustaf Neumann<ne...@wu...>
>> date: Sun Apr 11 17:16:27 2010 +0200
>> summary: Fix to prevent multiple DriverAccepts on the same socket.
>>               The original coded relied on the fact that later accepts lead to
>>               an ERROR_STATE. Under RHEL 4 (Power, 64bit) the second accept blocks.
>>
>>
>> diff --git a/nsd/driver.c b/nsd/driver.c
>> --- a/nsd/driver.c
>> +++ b/nsd/driver.c
>> @@ -1523,7 +1523,22 @@ SockAccept(Driver *drvPtr, Sock **sockPt
>>        * Accept the new connection.
>>        */
>>
>> - status = DriverAccept(sockPtr);
>> + /*
>> + * Hmmm: the original implementation was written in style that
>> + * DriverAccept was called twice, one to return for e.g. a simple,
>> + * new HTTP request NS_DRIVER_ACCEPT (staying in the SOCK_MORE
>> + * status), and then calling ACCEPT again, but which causes on our
>> + * RHEL 4 system (POWER6, 64bit) a hang: the second accept blocks,
>> + * while it returns under (most?) other system a
>> + * NS_DRIVER_ACCEPT_ERROR. It seems that the original code rely on
>> + * this ERROR handling. It is not clear to me, why the second call
>> + * to ACCEPT is necessary, when the socket is already available.
>> + */
>> + if (*sockPtrPtr) {
>> + status = NS_DRIVER_ACCEPT_ERROR;
>> + } else {
>> + status = DriverAccept(sockPtr);
>> + }
>>
>>       if (status == NS_DRIVER_ACCEPT_ERROR) {
>>           status = SOCK_ERROR;
>>      
>
>
>
>    
>> It is not clear to me, why the second call to ACCEPT is necessary, when the socket is already available.
>>      
>
>
> http://bitbucket.org/naviserver/naviserver/src/tip/nsd/driver.c#cl-1175 :
>
>
>          DriverThread():
>
>          if (waitPtr == NULL) {
>              /*
>               * If configured, try to accept more than one request,
> under heavy load
>               * this helps to process more requests
>               */
>
>              accepted = 0;
>              while (accepted<  drvPtr->acceptsize
>                     &&  drvPtr->queuesize<  drvPtr->maxqueuesize
>                     &&  PollIn(&pdata, drvPtr->pidx)
>                     &&  (n = SockAccept(drvPtr,&sockPtr)) != SOCK_ERROR) {
>
>                  switch (n) {
>                  ...
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>    

Re: [naviserver-devel] driver changes, please check

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

On Sun, Apr 11, 2010 at 4:42 PM, Gustaf Neumann <ne...@wu...> wrote:
>
> The current solution works, but returns the chunked markup
> (which is fine for me, doing the chunked-decode in Tcl),
> but should done in (similar to the chunked encoding for forms).


This is not going to work reliably because of the following, right?

http://bitbucket.org/naviserver/naviserver/changeset/a1ccb0371eee/#chg-nsd/driver.c_newline2239

        if (reqPtr->avail > reqPtr->expectedLength) {
            /*
             * Chunk encoded data is always larger than the expected
             * length; we hope that we have sufficient data collected
             */
            reqPtr->length = reqPtr->avail;
        } else {



> Actually, there must be a better way for this than the following
> change: http://bitbucket.org/naviserver/naviserver/changeset/a1ccb0371eee/


How about implementing chunked uploading?  It is a requirement of the
HTTP 1.1 spec.

There is already full support for writing chunked, with tests, and
there is support for parsing mime parts in the form parsing code.

Re: [naviserver-devel] driver changes, please check

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

On Sun, Apr 11, 2010 at 4:42 PM, Gustaf Neumann <ne...@wu...> wrote:
>
> PS: i had to do a "hg push -f ...". Not sure, if this is intentional.
> Do the commits to tip look right?


All that's happened here is that you've made changes to your checkout
without first updating it. In the meantime, Zoran has made changes and
pushed them.

If this were CVS it would refuse to let you commit. With mercurial
obviously you can commit as it's local, but it will not let you push
and will give you a warning. You ignored the warning by using -f  :-)

You are going to have to merge the two heads with 'hg merge' and then
push that changeset. See: hg help merge.

Re: [naviserver-devel] commit/naviserver: gustafn: - Fix to prevent multiple DriverAccepts on the same socket. The original coded relied on the fact that later accepts

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

On Sun, Apr 11, 2010 at 4:16 PM,  <com...@bi...> wrote:
>
> changeset: 2575:3963e46562e8
> user: Gustaf Neumann <ne...@wu...>
> date: Sun Apr 11 17:16:27 2010 +0200
> summary: Fix to prevent multiple DriverAccepts on the same socket.
>              The original coded relied on the fact that later accepts lead to
>              an ERROR_STATE. Under RHEL 4 (Power, 64bit) the second accept blocks.
>
>
> diff --git a/nsd/driver.c b/nsd/driver.c
> --- a/nsd/driver.c
> +++ b/nsd/driver.c
> @@ -1523,7 +1523,22 @@ SockAccept(Driver *drvPtr, Sock **sockPt
>       * Accept the new connection.
>       */
>
> - status = DriverAccept(sockPtr);
> + /*
> + * Hmmm: the original implementation was written in style that
> + * DriverAccept was called twice, one to return for e.g. a simple,
> + * new HTTP request NS_DRIVER_ACCEPT (staying in the SOCK_MORE
> + * status), and then calling ACCEPT again, but which causes on our
> + * RHEL 4 system (POWER6, 64bit) a hang: the second accept blocks,
> + * while it returns under (most?) other system a
> + * NS_DRIVER_ACCEPT_ERROR. It seems that the original code rely on
> + * this ERROR handling. It is not clear to me, why the second call
> + * to ACCEPT is necessary, when the socket is already available.
> + */
> + if (*sockPtrPtr) {
> + status = NS_DRIVER_ACCEPT_ERROR;
> + } else {
> + status = DriverAccept(sockPtr);
> + }
>
>      if (status == NS_DRIVER_ACCEPT_ERROR) {
>          status = SOCK_ERROR;




> It is not clear to me, why the second call to ACCEPT is necessary, when the socket is already available.



http://bitbucket.org/naviserver/naviserver/src/tip/nsd/driver.c#cl-1175 :


        DriverThread():

        if (waitPtr == NULL) {
            /*
             * If configured, try to accept more than one request,
under heavy load
             * this helps to process more requests
             */

            accepted = 0;
            while (accepted < drvPtr->acceptsize
                   && drvPtr->queuesize < drvPtr->maxqueuesize
                   && PollIn(&pdata, drvPtr->pidx)
                   && (n = SockAccept(drvPtr, &sockPtr)) != SOCK_ERROR) {

                switch (n) {
                ...

[naviserver-devel] driver changes, please check

[Gustaf N. <ne...@wu...>]

Dear driver experts,

i experienced problems with PUT operations with chunked
encodings. The existing code seems to rely on provided
content-lengths for client requests with content, which is
not available form e.g. PUT operations with chunked
encoding (e.g. issued from Finder under Mac OS X).
I would like to read such requests (which come with
"connection: close") until eof, but found no easy way for
do so.

With the original code, the content length for such requests
was always 0.

The current solution works, but returns the chunked markup
(which is fine for me, doing the chunked-decode in Tcl),
but should done in (similar to the chunked encoding for forms).

Actually, there must be a better way for this than the following
change: http://bitbucket.org/naviserver/naviserver/changeset/a1ccb0371eee/

all the best
-gustaf neumann

PS: i had to do a "hg push -f ...". Not sure, if this is intentional.
Do the commits to tip look right?

Re: [naviserver-devel] Where is ChangeLog?

[Vasiljevic Z. <zv...@ar...>]

Hi Stephen,

Thanks for taking trouble to convince us to move
to Mercurial. I like the thing very much. It is
lean, simple and fast. I am contemplating about
using it for all the in-house projectss as well!

Cheers,
Zoran

On 07.03.2010, at 00:35, Stephen Deasey wrote:

>
> I haven't read this yet, but I expect it's good:
>
>  http://hginit.com/

[naviserver-devel] security fix

[Gustaf N. <ne...@wu...>]

Hi,

please notice the change below, which protects against a security flaw
in connection with utf-8 canonicalization

http://bitbucket.org/naviserver/naviserver/changeset/837647e120c5/

See the lengthy comment for the details...

Best regards
-gustaf neumann

Re: [naviserver-devel] Where is ChangeLog?

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

On Sat, Mar 6, 2010 at 5:43 PM, Vasiljevic Zoran <zv...@ar...> wrote:
>
> On 06.03.2010, at 16:30, Vasiljevic Zoran wrote:
>
>> Or should I need to do some other "magic" after "hg ci" ???
>
> I see: "hg push".


Yeah, 'commit' is local, 'clone' and 'push' are like rsync up and down.

You can also do 'incoming' and 'outgoing' to see what's pending a
'push' or 'pull'.


I haven't read this yet, but I expect it's good:

  http://hginit.com/

Re: [naviserver-devel] Where is ChangeLog?

[Vasiljevic Z. <zv...@ar...>]

On 06.03.2010, at 16:30, Vasiljevic Zoran wrote:

> Or should I need to do some other "magic" after "hg ci" ???

I see: "hg push". 

Re: [naviserver-devel] Where is ChangeLog?

[Vasiljevic Z. <zv...@ar...>]

On 06.03.2010, at 16:18, Stephen Deasey wrote:

> Because of the way that mercurial works, when you 'clone' (ie. cvs

OK. So I "hg clone"'d, then made chage to a  nsd/tcljob.c file
then made "hg ci".
Observing the web-view of bitbucket.org/naviserver there was
nothing changed. I do not see my commit message nor can I see
any trace of my change when inspecting files.

When I do "hg log" I SEE my changes. When I do "hg status"
I DO NOT SEE my changes file prefixed with "M", which I
suppose is OK (changes were commited).

Is this all correct? Should I be able to see my commit
messgage and status of the changed file show up in the
web-browser? Or is this somehow cached/time-skewed?
Or should I need to do some other "magic" after "hg ci" ???

Cheers
Zoran

Re: [naviserver-devel] Mercurial does not substitute tags?

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

On Sat, Mar 6, 2010 at 1:18 PM, Vasiljevic Zoran <zv...@ar...> wrote:
> Hi!
>
> It seems to me that we miss RCS Tag substitution.
> Is this so deliberately? If yes, what's the point
> in keeping NS_RCSID any longer?
>
> < NS_RCSID("@(#) $Header: /Volumes/DATEN0/develop/local/CVS/dev/
> naviserver/nsd/queue.c,v 1.2 2008/04/29 08:11:15 zv Exp $");
> ---
>  > NS_RCSID("@(#) $Header$");


Mercurial doesn't mangle the source code by default. There is a
plugin, included but disabled by default, that can do this, but I
haven't tried it.

Not sure whether it's worth the bother to set that up, remove the
unused RCS tags, or just leave it be...

Re: [naviserver-devel] Where is ChangeLog?

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

On Sat, Mar 6, 2010 at 1:03 PM, Vasiljevic Zoran <zv...@ar...> wrote:
> Hi!
>
> After some (longer) absence (first things first) I am
> now trying to catch-up with the Mercurial repository.
>
> First thing that I noticed after checking out the
> repository was that ChangeLog file is missing.
> Any idea why? Do we not need it any more?


That's right, it's not needed anymore.

Because of the way that mercurial works, when you 'clone' (ie. cvs
checkout) you get the whole repository on your local hard drive, not
just the HEAD (which we now call 'tip').

So, when you do a 'hg log' you can see all changes ever made without
hitting the network.

Also, if you want something easier to browse, try doing 'hg serve' and
then connecting to localhost with your browser.

[naviserver-devel] Where is ChangeLog?

[Vasiljevic Z. <zv...@ar...>]

Hi!

After some (longer) absence (first things first) I am
now trying to catch-up with the Mercurial repository.

First thing that I noticed after checking out the
repository was that ChangeLog file is missing.
Any idea why? Do we not need it any more?

More questions are sure to come...

Cheers,
Zoran

[naviserver-devel] Mercurial does not substitute tags?

[Vasiljevic Z. <zv...@ar...>]

Hi!

It seems to me that we miss RCS Tag substitution.
Is this so deliberately? If yes, what's the point
in keeping NS_RCSID any longer?

< NS_RCSID("@(#) $Header: /Volumes/DATEN0/develop/local/CVS/dev/ 
naviserver/nsd/queue.c,v 1.2 2008/04/29 08:11:15 zv Exp $");
---
 > NS_RCSID("@(#) $Header$");

Cheers
Zoran

Re: [naviserver-devel] spooler not working on linux

[John B. <jo...@ma...>]

> I just tried upload.tcl on my 32bit linux, latest sources with
> maxupload 10000000
> maxinput 8904984589
> works without problem, memory usage during upload of the nsd process stays the same and in /tmp i can see the file is growing
> i attached piece from my log, at the end there should be line reporting about the file, i do not see it in your log file

Oddly, large file works fine on aolserver with these settings, but naviserver does a connection reset on my linux server, but works on osx and on your linux servers.  

Vlad, I ported your ns_parseformfile function over to aolserver, where it's working for me, and I now have large file uploads working on aolserver, so sadly I'm off naviserver.

I'll try moving back to naviserver again when I upgrade the linux version (it's running a 4 year old Ubuntu) on my server, as I do like a lot of the things you guys have added to naviserver (and that it's in such active development). 

-john

Re: [naviserver-devel] spooler not working on linux

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

I just tried upload.tcl on my 32bit linux, latest sources with

maxupload 10000000
maxinput 8904984589

works without problem, memory usage during upload of the nsd process 
stays the same and in /tmp i can see the file is growing

i attached piece from my log, at the end there should be line reporting 
about the file, i do not see it in your log file

John Buckman wrote:
> I've enabled debugging to try to find the spooler-on-linux problem I'm having.  Unfortunately, I don't think it's very enlightening:
> 
> [-driver:nssock-] Debug: Spooler: 0: started fd=7: 1687742 bytes
> [-conn:amagnatune:0] Debug: ns:interptrace[amagnatune]: create nslog:initinterp /usr/local/naviserver/logs/access.log
> [-conn:amagnatune:0] Debug: ns:interptrace[amagnatune]: allocate ns:tcltrace ns_init
> [-conn:amagnatune:0] Notice: upload.tcl: /upload.tcl: 
> [-conn:amagnatune:0] Debug: ns:interptrace[amagnatune]: deallocate ns:tcltrace ns_cleanup
> 
> Once, I also saw this (but not on repeated runs) which shows the driver debug info is being logged:
> [-driver:nssock-] Debug(ns:driver): SockRelease: Unable to shutdown socket (9: Bad file descriptor), sock: -1, peer: 64.62.148.4:3361, request: 
> 
> I'm using Vlad's upload.tcl example, to keep things simple. I'm attaching the larger naviserver startup log, in case that helps.
> 
> When I set 
> ns_param maxupload      2048000000
> 
> the debug log implies the spooler is working correctly, it's just that the old-style MIME parser kicks in at the end, using lots of memory:
> [-driver:nssock-] Debug: Spooler: 0: started fd=7: 1687742 bytes
> [-conn:amagnatune:0] Debug: ns:interptrace[amagnatune]: create nslog:initinterp /usr/local/naviserver/logs/access.log
> [-conn:amagnatune:0] Debug: ns:interptrace[amagnatune]: allocate ns:tcltrace ns_init
> [-conn:amagnatune:0] Notice: upload.tcl: /upload.tcl: 778212 1687742
> [-conn:amagnatune:0] Debug: ns:interptrace[amagnatune]: deallocate ns:tcltrace ns_cleanup
> [-conn:amagnatune:0] Debug: ns:interptrace[amagnatune]: allocate ns:tcltrace ns_init
> [-conn:amagnatune:0] Notice: upload.tcl: /upload.tcl: 1074812 1687742
> [-conn:amagnatune:0] Debug: ns:interptrace[amagnatune]: deallocate ns:tcltrace ns_cleanup
> [-conn:amagnatune:0] Debug: ns:interptrace[amagnatune]: allocate ns:tcltrace ns_init
> [-conn:amagnatune:0] Notice: upload.tcl: /upload.tcl: 1383236 1687742
> [-conn:amagnatune:0] Debug: ns:interptrace[amagnatune]: deallocate ns:tcltrace ns_cleanup
> [-conn:amagnatune:0] Debug: ns:interptrace[amagnatune]: allocate ns:tcltrace ns_init
> [-conn:amagnatune:0] Notice: upload.tcl: /upload.tcl: 1687316 1687742
> [-conn:amagnatune:0] Debug: ns:interptrace[amagnatune]: deallocate ns:tcltrace ns_cleanup
> [-spooler0-] Debug: spooling content to file: readahead=1024, filesize=1687743
> [-conn:amagnatune:0] Debug: ns:interptrace[amagnatune]: allocate ns:tcltrace ns_init
> [-conn:amagnatune:1] Debug: ns:interptrace[amagnatune]: create nslog:initinterp /usr/local/naviserver/logs/access.log
> [-conn:amagnatune:1] Debug: ns:interptrace[amagnatune]: allocate ns:tcltrace ns_init
> [-conn:amagnatune:0] Debug: ns:interptrace[amagnatune]: deallocate ns:tcltrace ns_cleanup
> [-conn:amagnatune:1] Notice: upload.tcl: /upload.tcl: 
> [-conn:amagnatune:1] Debug: ns:interptrace[amagnatune]: deallocate ns:tcltrace ns_cleanup
> 
> Other question you guys had:
> 
> - CVS -- I had previously used the sourceforge CVS from my memory, there wasn't a link I followed.  I'm now using the bitbucket source.
> 
> - nslog - I added "ns_logctl severity Debug(ns:driver) true" to my config file.
> 
> -john
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

-- 
Vlad Seryakov
vl...@cr...
http://www.crystalballinc.com/vlad/