Hi,
I've been trying to get aolserver to run on Valgrind for a week now
and it does work to a certain extent. My Aolserver interfaces with
Oracle databases and my problem is that when I do run aolserver on
valgrind and nsoracle driver attempts to connect to Oracle, I get a
OCIServerAttach ()': OR
ufflick <[EMAIL PROTECTED]> wrote:
> Not that this helps you, but I successfully run aolserver under
> valgrind without any database module loaded.
>
>
>
> On Tue, Sep 2, 2008 at 11:14 AM, Sep Ng <[EMAIL PROTECTED]> wrote:
> > Hi,
>
> > I've been trying t
Hi,
I've been spending a load of time reading through the aolserver source
code and fiddling with my configurations. I put this on my aolserver
parameters:
ns_section "ns/server/testsite/adp/compress"
ns_param enabled true
ns_param level 4
ns_param minsize 1024
I
t know anything about it, but I do remember this
> > discussion from last year
> > http://www.mail-archive.com/aolser...@listserv.aol.com/msg11654.html
>
> > hope this helps somewhat
> > Brian
> > ________
> > From: AOLserver Discussion [a
t; nginxhttp://cognovis.de/developer/en/nginx-loadbalancing
>
> cheers
> Brian
>
>
> From: AOLserver Discussion [aolser...@listserv.aol.com] On Behalf Of Sep Ng
> [thejackschm...@gmail.com]
> Sent: 30 April 2009 17:04
> To: aolser...@l
Quick update:
Just recompiled AOLserver 4.0.10 with the gzip path and still no go.
I suppose I will scout the bug tracker on sourceforge to see if I find
anything interesting. I wonder what problems did OpenACS introduce
into this gzip issue...
On May 1, 5:25 am, Sep Ng wrote:
> I rea
l and not handled by aolserver. That's a bit weird,
but I think it'll do for now.
Thanks to everyone for helping out here.
On May 1, 8:31 am, Sep Ng wrote:
> Quick update:
>
> Just recompiled AOLserver 4.0.10 with the gzip path and still no go.
> I suppose I will scout the bu
I'm working on this on behalf of Jade and I'd like to get some info on
adding thread safe code on TLS. As noted by Andrew (huge thanks!),
TLS does not set the CRYPTO_set_locking_callback and
CRYPTO_set_id_callback callback functions which would be required to
have TLS thread safe code. I was work
t; For CRYPTO_set_id_callback, it looks like Tcl_GetCurrentThread is the
> right callback.
>
> On 4-May-09, at 7:43 PM, Sep Ng wrote:
>
> > I'm working on this on behalf of Jade and I'd like to get some info on
> > adding thread safe code on TLS. As noted by A
at as far as I understand, OpenSSL
specifies that the functions must support n mutex locks where n is
extracted from CRYPTO_num_locks().
I'll see if it is possible to do this with TCL_DECLARE_MUTEX.
I appreciate all the info thus far. :)
On May 5, 1:06 pm, Sep Ng wrote:
> Thanks for the li
I certainly hope I'm not spamming but this is likely to be the last
update of the day (at least on my end).
I wrote a pretty sketchy (and lots of bad programming) but I think I
*might* have gotten the mutex initialization done. Unfortunately, on
tests, it falls on a segmentation fault on exactly t
used, but it might help debug.
>
> On 05/05/2009 12:55 AM, Sep Ng wrote:
>
>
>
> > I certainly hope I'm not spamming but this is likely to be the last
> > update of the day (at least on my end).
> > I wrote a pretty sketchy (and lots of bad programming) but I
are other avenues to this, maybe even using the standard
malloc might do.
On May 6, 6:42 am, Sep Ng wrote:
> I'll try it. I didn't give it much thought at first but looking at it
> again, I think it might prevent the long string of ns_free and other
> calls to free memory after D
gt; test it in your environments. I have tested that it passes the basic
> tls test suite against a threaded Tcl 8.5.7 core build on Linux-x64 (and
> verified that OPENSSL_THREADS was true for this install).
>
> This patch is against tls 1.6 head.
>
> Jeff
>
> On 05/05/2009 3:42 PM,
wrote one based on those presented. It is attached. Please test it in
> > your environments. I have tested that it passes the basic tls test suite
> > against a threaded Tcl 8.5.7 core build on Linux-x64 (and verified that
> > OPENSSL_THREADS was true for this install).
>
&
ssl and tls are in use, and that they
> both might be initializing openssl in the same process? I'm not sure if
> this would be a support case if so.
>
> On 05/05/2009 6:16 PM, Sep Ng wrote:
>
> > Hi Jeff,
>
> > I took a closer look at the patch you posted.
> discussion. I'll try to check the startup routine of aolserver and see if I
> can find anything.
>
> 2009/5/7 Jeff Hobbs
>
>
>
> > Is it possible that both nsopenssl and tls are in use, and that they both
> > might be initializing openssl in the same process
ved by default configure.
>
> https://sourceforge.net/tracker/?func=detail&aid=1811445&group_id=132...
>
> Jeff
>
> On 06/05/2009 6:45 PM, Sep Ng wrote:
>
>
>
> > Hi Jeff,
>
> > I'm going to review options on how to progress with this problem with
Hi,
I'm trying to debug an AOLserver crash and the point of crash seems to
be AppendConn in NS_GetProcInfo... I will post the stack trace after
just for reference.
Looking through the ticket tracker on AOLserver, I found two tickets
of particular interest:
http://dev.aolserver.com/trac/ticket/32
09 at 10:19 AM, Jim Davidson
> >>>> wrote:
> >>>>Hi,
>
> >>>>Do you have some sort of background job that calls
> >>>>"ns_server active" (or similar) regularly? That could
> >
his for a few
> > additional ns_conn options.
>
> > Gustaf's idea is easier to pull off at least initially, but it
> > shouldn't
> > be tied to an unrelated option like debugging. I leave on debugging
> > for
> > low traffic servers and I can also tu
Hi Dossy,
To be frank, the only reason why I keep using the Trac ticket tracker
is that it's the one I found. Had I known that the sourceforge ticket
tracker was the active one, I would have used that one instead. Begs
to question though... why two ticket trackers?
Anyway, thanks everyone for a
I think this has been a very interesting conversation. I would like
to simply stress that no matter what technology we use, it does not
inherently solve any of the problem. So, Sourceforge or Trac itself
does not solve the problem. If we manage to identify the problem,
then we can find the techn
I'm handling aolserver 4.0.10 and yeah, I know it's kind of old. If
I'm not mistaken, ns_info threads was not totally thread safe in that
version and it caused quite a few crashes here. I think I've managed
to get that number of crashing down a bit with mutex and a bit of
aolserver 4.5 code, but
_server active", it's really
> designed for live diag work, not so much as a background health check.
>
> -Jim
>
> On May 31, 2009, at 7:53 PM, Sep Ng wrote:
>
>
>
> > I'm handling aolserver 4.0.10 and yeah, I know it's kind of old. If
> > I&#x
what I can find.
On Jun 2, 3:42 pm, Gustaf Neumann wrote:
> Sep Ng schrieb:> Is there a way in AOLserver to do live monitoring on
> > threads? We're sort of hoping to get info on what thread ids are
> > running as of the moment on aolserver.
>
> The xotcl-reques
r
> > the application needs, or ffone can to extend the
> > xotcl-request monitor to track this information as well.
>
> > just to get the information about running connection
> > threads from the xotcl-request-monitor, use
> > "throttle running".
&g
any action taken or omitted to be
> taken in reliance to it, is prohibited.
>
>
>
> On Tue, Jun 2, 2009 at 6:28 PM, Sep Ng wrote:
> > Hello everyone,
>
> > I would like to say first of all I appreciate all the thought and
> > ideas you've brought to the table
Hi,
I was looking over the discussion here...
http://groups.google.com/group/aolserver/browse_thread/thread/7efbe7faff45419a?pli=1
And I've been experiencing something similar with 64-bit compiled
Aolserver 4.0 release 10 wherein the cpu processing leaps to 100% or
more, and memory consumption ju
Thanks for the swift reply Gustaf. I have Debian Etch on 64-bit as
the OS platform and I'm thinking that OS choice should not
particularly affect performance, right?
Thanks for the response!
Regards.
On Jun 14, 2:22 pm, Gustaf Neumann wrote:
> Am 14.06.10 05:11, schrieb Sep Ng:>
give me some hint on debugging techniques on aolserver.
Thanks very much for your insight.
On Jun 15, 3:09 pm, Gustaf Neumann wrote:
> Am 14.06.10 09:24, schrieb Sep Ng:> Thanks for the swift reply Gustaf. I
> have Debian Etch on 64-bit as
> > the OS platform and I'm thinking
Hi,
I've been looking into building some thread intensive applications on
top of aolserver (both on 4.0.10 and 4.5.1) and from experience, it
seems that this maybe one of the easier points to get wrong and crash
aolserver. I've wanted looked for documentation before but there does
not seem to be
hts and hope to hear more!
On Jun 30, 12:59 am, Jeff Hobbs wrote:
> On 28/06/2010 11:25 PM, Sep Ng wrote:
>
> > 2. I read that in Windows, thread destruction can cause instability
> > and possible memory leaks. Does this extend to other OS platforms?
>
> Just to hi
On Jun 30, 8:27 am, Gustaf Neumann wrote:
> Am 30.06.10 00:23, schrieb Sep Ng:> Basically we had aolservers running and
> while serving pages, it's also
> > doing some heavy load processing from a ton of scheduled custom
> > written procedures. Aolserver crashes a
On Jul 1, 4:59 am, Andrew Piskorski wrote:
> On Tue, Jun 29, 2010 at 03:23:38PM -0700, Sep Ng wrote:
> > Basically we had aolservers running and while serving pages, it's also
> > doing some heavy load processing from a ton of scheduled custom
> > written procedures.
>
On Jul 1, 5:21 am, Andrew Piskorski wrote:
> On Tue, Jun 29, 2010 at 06:19:06PM -0700, Sep Ng wrote:
> > How can I tell which ones are thread safe? This sounds like something
> > I will need to look into before I start writing code.
>
> *All* AOLserver modules must be threa
On Jul 1, 10:42 am, Andrew Piskorski wrote:
> On Wed, Jun 30, 2010 at 05:21:40PM -0400, Andrew Piskorski wrote:
> > If you manage to find a list somewhere of what MS Windows library
> > calls are or are not thread-safe, then you could use various tools to
> > find ALL the calls in your AOLserver b
and I have yet to go through the links Andrew provided but
thought I'd throw this update out there.
On Jul 1, 11:13 am, Sep Ng wrote:
> On Jul 1, 10:42 am, Andrew Piskorski wrote:> On Wed, Jun
> 30, 2010 at 05:21:40PM -0400, Andrew Piskorski wrote:
> > > If you manage
Hi,
Can I ask what nature of the crash this fixes? I remember trying
nsoracle 2.8 fork and it was extremely unstable and had to rollback to
2.7. Is this on the CVS tree now?
Thanks!
On Aug 26, 4:56 am, Andrew Steets wrote:
> Hello,
>
> I just checked in a patch for the Oracle driver that fixe
o reliably reproduce the crash?
>
> -Andrew
>
>
>
> On Wed, Aug 25, 2010 at 6:15 PM, Sep Ng wrote:
> > Hi,
>
> > Can I ask what nature of the crash this fixes? I remember trying
> > nsoracle 2.8 fork and it was extremely unstable and had to rollback to
>
Hi,
I've been trying to use nsmemcache and integrate it with aolserver but
I noticed that there's this bug where if you retrieve data over 2kb,
the data gets truncated. After inspection, it looks like it's because
the buffer size allocated when reading the contents via Ns_SockRecv is
not adequate
Hi Andrew,
It seems that the changes you did improved the stability of
aolserver. I will observe more of this, but the patch is looking
good.
On Aug 27, 6:13 am, Sep Ng wrote:
> Thanks for letting me know, Andrew. I will try to get around to
> testing the latest code base from C
conn_read(conn, BUFSIZE, 0, &line);
+rc = mc_conn_read(conn, bufsize, 0, &line);
}
if (strstr(conn->ds.string, "END\r\n") == NULL) {
- rc = mc_conn_read(conn, BUFSIZE, 0, &line);
+ rc = mc_conn_read(conn, bufsize, 0, &line);
Majid,
I will be more than happy to do it. I just probably need to figure
how and where to git pull. I don't think I have an account however.
Regards.
On Sep 4, 5:03 am, Majid Khan wrote:
> Yes just remove what's there because there are multiple/redundant copies of
> the same file so its very
merge it in.
>
> On 8/31/10 7:17 PM, Sep Ng wrote:
>
> > Okay, I guess I'll simply post the diff patch here for anyone who
> > needs it.
>
> --
> Dossy Shiobara | do...@panoptic.com |http://dossy.org/
> Panoptic Computer Network |http://panoptic.
I have run some tests and Majid's changes fixed the bug, so I don't
think my patch is relevant anymore.
Cheers.
On Sep 4, 11:12 am, Sep Ng wrote:
> Yes sir! As soon as possible, I will look at it and determine whether
> it's still relevant. I'll post a new diff if n
I have tested your code updates Majid and they work splendidly!
On Sep 4, 10:54 am, Dossy Shiobara wrote:
> I have committed Majid's code to GitHub that he has sent to me and have
> tagged it version 1.1. You can download the tarball for it using this URL:
>
> http://github.com/aolserver/nsm
Jeff is right. Make sure also that your user account that you use
when binding the ports has proper permissions to do so.
On Oct 28, 10:16 am, Jeff wrote:
> Note this line in your startup log:
> [27/Oct/2010:17:23:55][13466.3061930912][-nsopenssl:driver-] Notice:
> nsopenssl: listening on 64.5
443 is a privileged port, I believe. If you're specifying a specific
user for aolserver (-u parameter) then that user has to have access to
port 443, I think.
On Oct 28, 10:50 am, Thorpe Mayes wrote:
> Jeff,
>
> Thanks for the reply and the advice.
>
> Tried it and got this:
>
> 27/Oct/2010:21:4
Hi,
I'm running on AOLserver 4.5.1 and everything for the most part seems fine.
On occasion, I get this error message when the server tries to get a db
handle:
could not allocate 1 handle(s) from pool "default"
>From what I know, it should mean that AOLserver ran out of database pools to
use.
Hi,
Is there a way of killing the threads once max connection has been reached
or does aolserver automatically take care of this?
Regards
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
with the
body of "SIGNOFF AOLSERVER" in the email mes
>From my own experience, it seems that I get a ton of that like all the
threads (or a majority of them) have exceeded max connections and it seems
that it does take a while before they start serving again. I'd like to know
if this is normal or should the turn around time be a lot quicker...
Th
52 matches
Mail list logo
