Re "... I don't think there's a huge number of sites using AOLserver ..."
I have several that have been running for six years, but I do not choose or
want to heavily advertise that they use AOLServer. What matters to me is
that they are rock solid, performance is never an issue, and that I have
i
On Fri, May 29, 2009 at 7:20 PM, Dossy Shiobara wrote:
> To quickly summarize:
>
> 1) Dave Bauer identifies the "lack of anyone doing anything about [open]
> bugs" and the lack of "process or resources to deal with the bugs" as a
> problem.
>
I really agree more with Tom. I just meant that votin
i see it the same way as tom. Aolserver is in a good shape and has no
critical
bugs. The few severe issues showing up in the last few years were repaired
in short time. I am not sure, what kind of problems dave has with the
"list of bugs", aside optics; i dout he has a real issue with this.
Sur
Hi all -- This list does not hear from me much, but I agree with Tom's
assessment of the state of AOLserver. Our bugs compared to other "more
staffed" open source projects are far less and far fewer. In addition,
I have been working with Open Source for many years and I used
extensively, Apache,
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
Maybe I'm being too ambiguous. Do we have any critical bugs? I don't
think so. Yes, the ticket tracker might have unresolved "tickets". But
just because we have stuff in our ticket tracker doesn't mean that any
particular item actually needs or demands resolution.
As I have stated before, most bu
To quickly summarize:
1) Dave Bauer identifies the "lack of anyone doing anything about [open]
bugs" and the lack of "process or resources to deal with the bugs" as a
problem.
2) Tom Jackson identifies that there's little in-community support for
would-be contributors to get their changes me
On 5/29/09 4:16 PM, Tom Jackson wrote:
Forcing me to interact with a ticket tracker wouldn't improve my
community involvement, it would probably make contributions even less
likely.
What might help me, and maybe others, would be a weekly email summary of
unfinished business, dropped balls, or wh
On Fri, 2009-05-29 at 16:31 -0400, Dave Bauer wrote:
> In the case of the bug tracker, the bug tracking software is clearly
> NOT the problem, but the lack of anyone doing anything about those
> bugs on way or the other. Until that is addressed any effort to
> change the presentation of the bugs
On Fri, May 29, 2009 at 1:27 PM, Jade Rubick wrote:
> Personally, even though I think many in the community don't like Dossy
> acting without community involvement, I'd rather see something done than
> nothing, as long as it isn't harming the project.
>
> Perhaps the problem is that there is no f
How many active tickets do we have on sourceforge? How many developers
do we have working on tickets? How many tickets/issues are worked on by
several people without broader community input?
My sense is that the same handful of developers respond to a half dozen
real bugs/issues per year. Half th
On 5/29/09 1:27 PM, Jade Rubick wrote:
Personally, even though I think many in the community don't like Dossy
acting without community involvement, I'd rather see something done than
nothing, as long as it isn't harming the project.
I definitely understand that people dislike my approach. I al
Personally, even though I think many in the community don't like Dossy
acting without community involvement, I'd rather see something done than
nothing, as long as it isn't harming the project.
Perhaps the problem is that there is no formal structure for Aolserver, so
nobody has the "authority" to
On 5/21/09 4:32 AM, Sep Ng wrote:
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?
We
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
On 5/20/09 11:11 AM, Jim Davidson wrote:
Yup -- agreed. I was talking with Dossy who says the Trac stuff is
generally out of date anyway, the definitive bug list is still on
Sourceforge (definitive in it's the place, can't say how accurate the
bug reports are).
I would love to hear that the A
I also checked on the other ticket I mentioned on the commit logs and
it seems that the ticket may have been addressed with aolserver 4.5
too... so I think it's looking like everything is resolved.
On May 20, 11:11 pm, Jim Davidson wrote:
> Yup -- agreed. I was talking with Dossy who says the T
Yup -- agreed. I was talking with Dossy who says the Trac stuff is
generally out of date anyway, the definitive bug list is still on
Sourceforge (definitive in it's the place, can't say how accurate the
bug reports are).
-Jim
On May 15, 2009, at 6:35 PM, Jack Schmidt wrote:
I guess
I guess if it's thread safe now, the ticket should be closed with a
reference to aolserver 4.5.
2009/5/16 Jim Davidson
> Hi,
>
> I'm looking at the head code and it appears it's now safe -- the connection
> list is walked with a pool lock held and the request data (method, url) seem
> to be copi
4.0.10
J
Jade Rubick
Director of Development
TRUiST
120 Wall Street, 4th Floor
New York, NY USA
jrub...@truist.com
+1 503 285 4963
+1 707 671 1333 fax
www.truist.com
The information contained in this email/document is confidential and may be
legally privileged. Access to this mail/document by
Hi,
I'm looking at the head code and it appears it's now safe -- the
connection list is walked with a pool lock held and the request data
(method, url) seem to be copied with a global "reqlock" mutex held.
Jade: What version of AOLserver are you using?
-Jim
On May 15, 2009, at 10:06 A
One thing which would be nice is to put the Tcl API into a module which
as to be loaded, and keep the C API available in the core. It is
obviously more work, but the admin has to make a choice to load the Tcl
API, which is more open to misuse. I did something like this for a few
additional ns_conn
Tom Jackson schrieb:
On Thu, 2009-05-14 at 18:08 -0400, Jim Davidson wrote:
Good idea. Maybe it would make sense to disable it by default with
some config flag to enable?
I was thinking the same, but I wasn't sure how many people actually use
this command.
i would even recommend
How about having the proc enable only if debug settings are turned on
on AOLserver?
On May 15, 6:08 am, Jim Davidson wrote:
> Good idea. Maybe it would make sense to disable it by default with
> some config flag to enable?
> Jim
>
> Sent from my iPhone
>
> On May 14, 2009, at 4:49 PM, Tom Jackso
On Thu, 2009-05-14 at 18:08 -0400, Jim Davidson wrote:
> Good idea. Maybe it would make sense to disable it by default with
> some config flag to enable?
I was thinking the same, but I wasn't sure how many people actually use
this command.
This must be one of a very few commands that I have n
Good idea. Maybe it would make sense to disable it by default with
some config flag to enable?
Jim
Sent from my iPhone
On May 14, 2009, at 4:49 PM, Tom Jackson wrote:
Maybe calling the API should result in a ns_log Warning to indicate a
potential crash.
tom jackson
On Thu, 2009-05-14 at
Maybe calling the API should result in a ns_log Warning to indicate a
potential crash.
tom jackson
On Thu, 2009-05-14 at 13:26 -0700, Jade Rubick wrote:
> I'm just happy we figured it out.
>
>
> We were using this call:
>
>
> set connections [ns_server active]
>
>
> But it wasn't in a sche
I'm just happy we figured it out.
We were using this call:
set connections [ns_server active]
But it wasn't in a scheduled proc, so I just moved it behind a
password protection section, and put a warning around it. We seldom
(never) used that page anyway. I think a bot may have found it or
Yup -- should really have been documented better -- sorry about that.
Anyway, what is the monitoring attempting to dig up? There may some
other safe ways to get the same.
-Jim
On May 14, 2009, at 2:04 PM, Jade Rubick wrote:
Ironically, we have some monitoring code that does use that
Ironically, we have some monitoring code that does use that functionality.
So our monitoring is killing our servers. Nice!
I'm removing that code now.
Jade Rubick
Director of Development
TRUiST
120 Wall Street, 4th Floor
New York, NY USA
jrub...@truist.com
+1 503 285 4963
+1 707 671 1333 fax
ww
Hi,
Do you have some sort of background job that calls "ns_server
active" (or similar) regularly? That could lead to random crashes.
The description in http://dev.aolserver.com/trac/ticket/152 is
accurate: The code, by design, is not strictly safe as it's assumed
to only be used intera
31 matches
Mail list logo
