Re: [AOLSERVER] Checked in some code
--- Jim Davidson <[EMAIL PROTECTED]> wrote: > Hi, > > I just checked in several changes to the 4.5 HEAD > branch. The > ChangeLog was updated with some notes. Briefly: > > - Finished up support for large content in > temp-files. > - Added new routines to access uploaded files in C, > e.g., Ns_ConnGetFile Thanks very much for getting that in there. My attached diffs include a routine for the application to know whether the content is in RAM or on disk before calling Ns_ConnGetQuery. This will allow the application to treat larger uploads differently from small ones. My code compiles, but I haven't tested it yet. It's pretty straightforward, though. Ideally, when the file is big, it could be parsed as it's being read in, but I should get some sleep tonight. ;-) > - Added a new ns_cache command based on ideas from > nscache module. > It's a re-write closer to some code we had here at > AOL and not fully > compatible with nscache (which you can of course > still load to > override this implementation). > - Added routines for multi-threaded send of open > files. Thanks again. > - Other code cleanup changes which look big but are > really just > routine and/or struct name changes to avoid dups > across files (this > helps with ctags and when setting breakpoints). > > Now brace yourself: In addition to the code, I have > actually checked > in some man pages this time, including for the new > Ns_ConnFile > API's! And, I created a Makefile in the doc > directory which should > make it easier to install and cross link the docs > going forward. The > Makefile also has a "missing" target to list public > routines without > man pages (there are several right now). > This is very much appreciated by us newbies to AOLserver. My diffs include a fix for installing the docs to a different prefix, or if there wasn't a preinstalled AOLserver. It was trying to get Makefile.global from the installed AOLSERVER directory, instead of from ../include. If it's a clean machine, this file won't exist. If it's had a previously installation to the default /usr/local/aolserver, the docs overwrite the default ones. Let me know whether you'd like to incorporate some, all, or modify my diffs. Thanks, Fred > Of course most of the man pages are still > placeholders -- I'm open to > suggestions on how we can get moving filling them in > again. > > -Jim > > > -- > AOLserver - http://www.aolserver.com/ > > To Remove yourself from this list, simply send an > email to <[EMAIL PROTECTED]> with the > body of "SIGNOFF AOLSERVER" in the email message. > You can leave the Subject: field of your email > blank. > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank. diffs Description: 2814508393-diffs
Re: [AOLSERVER] Server not stopping properly
This should be in the code now -- check the "shutdownPending" static var in nsd/sched.c. The behavior should be that as soon as shutdown begins, this flag is set an no new sched procs can be created or kicked off. There could be a bug in there. Of course if a thread-based proc is running or a non-thread based proc is taking a long time, this flag will not be seen as it's at the C level and requires control to return from the users callback. -Jim On Jul 18, 2005, at 8:53 PM, Janine Sisk wrote: Wouldn't it make sense for the scheduler to stop starting up new proc runs once it knows the server is shutting down? It's not like these are long running things; they are starting up very frequently because they only run for a few seconds and then finish. So it wouldn't be a big issue if the ones that were running when the server was shut down were allowed to finish; the problem is that the scheduler is keeping on going, running more of them, seemingly forever. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
[AOLSERVER] access log getting wiped
Can anyone suggest why this might be happening? Instead of being rolled,
my access log is gettting removed. Ie. a new one is started each day as
expected, but the backups are not kept.
My nslog config section is:
ns_section ns/server/${server}/module/nslog
ns_param debug false
ns_param devfalse
ns_param enablehostnamelookup false
ns_param file ${serverroot}/log/${server}.log
ns_param logcombinedtrue
#ns_param extendedheaders
COOKIE
ns_param extendedheadersX-User-Id
#ns_param logrefer
false
#ns_param loguseragent
false
ns_param logreqtime true
ns_param maxbackup 1000
ns_param rollday*
ns_param rollfmt%Y-%m-%d-%H:%M
ns_param rollhour 0
ns_param rollonsignal true
ns_param rolllogtrue
--
Mark Aufflick
e: [EMAIL PROTECTED]
w: www.pumptheory.com (business)
w: mark.aufflick.com (personal)
p: +61 438 700 647
f: +61 2 9436 4737
iBurst Wireless Broadband from $34.95/month www.platformnetworks.net
Forward undetected SPAM to: [EMAIL PROTECTED]
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] Server not stopping properly
On Monday 18 July 2005 17:53, Janine Sisk wrote: > Wouldn't it make sense for the scheduler to stop starting up new proc > runs once it knows the server is shutting down? It's not like these > are long running things; they are starting up very frequently because > they only run for a few seconds and then finish. So it wouldn't be a > big issue if the ones that were running when the server was shut down > were allowed to finish; the problem is that the scheduler is keeping > on going, running more of them, seemingly forever. Janine, My suggestion is to never use the -t option. Just use -k. If you have a scheduled proc that really needs to finish no matter what, you probably need to have some kind of progress indicator. I had proposed similar changes to my cron module for OACS, but never completed the work. But if the job is important, I woundn't rely on AOLserver alone to handle it, because even if the job wasn't running at the time you did the restart, it might have been scheduled at a time during the restart. tom jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] access log getting wiped
On 2005.07.19, Mark Aufflick <[EMAIL PROTECTED]> wrote:
> Can anyone suggest why this might be happening? Instead of being rolled,
> my access log is gettting removed. Ie. a new one is started each day as
> expected, but the backups are not kept.
>
> My nslog config section is:
...
>ns_param maxbackup 1000
You should be seeing an error in your log from this from Ns_RollFile():
if (max < 0 || max > 999) {
Ns_Log(Error, "rollfile: invalid max parameter '%d'; "
"must be > 0 and < 999", max);
return NS_ERROR;
}
Needs to be <= 999. (Heh, error message is wrong, too.)
-- Dossy
--
Dossy Shiobara mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
[AOLSERVER] Charset problem
Hi all, I've just made a mess for myself and I'm hoping someone will know how to fix it. It's really more of an Oracle problem and the message below is a modified version of one i just sent to an Oracle list, but I thought perhaps someone here would have already struggled with it. I took a site that was running under 8.7.1.4 and moved it to 9.2.0.4 (both on RedHat Linux) using exp/imp. I didn't specify a character set in either case. The data has accented characters and they have been working fine in 8.1..7.4. Now, it seems that the default setting of NLS_CHARACTERSET in 8.1.7.4 was US7ASCII and in 9.2.0.4 it's WE8ISO8859P1. Everything I've read about this conversion says that since it's going from 7 bit to 8 bit there shouldn't be any data problems. Well, hah! :) We didn't spot any at first, but now that the client is looking closely he's finding pages all over the place that have ?? where accented characters should be. The problem was even worse at first; some characters displayed ok until you edited the page via the web browser, and then they turned into ?? as well. I was able to fix that, as far as I can tell, by setting NLS_CHARACTERSET to WE8ISO8859P1 in the environment of the user running the site. It has not, unfortunately, helped us with the rest of the mess. AOLserver is configured to use iso-8859-1 for it's charset and has been all along. The only thing that has changed here is the Oracle version and it's charset. I have this in the ns/parameters section: ns_param HackContentType1 ns_param DefaultCharset iso-8859-1 ns_param HttpOpenCharsetiso-8859-1 ns_param OutputCharset iso-8859-1 ns_param URLCharset iso-8859-1 Going back and reimporting the data is a last resort, as we'd either lose or recreate user data that has been entered since the site was moved on Sunday night. Is there anything else I can do to fix this? In short, heeelp! :) thanks, janine -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Charset problem
On 2005.07.19, Janine Sisk <[EMAIL PROTECTED]> wrote: > Now, it seems that the default setting of NLS_CHARACTERSET in 8.1.7.4 > was US7ASCII and in 9.2.0.4 it's WE8ISO8859P1. Everything I've read > about this conversion says that since it's going from 7 bit to 8 bit > there shouldn't be any data problems. Well, hah! :) We didn't spot > any at first, but now that the client is looking closely he's finding > pages all over the place that have ?? where accented characters should > be. If you had accented characters (octets with the 8th bit set to 1) stored in the database under 8.1.7.4, then there is NO way the character set of the database was US7ASCII. If it was, then when the data was stored it would have been transcoded to ?'s. You will need to re-exp the data setting NLS_CHARSET to WE8ISO8859P1 before doing the exp. Then, imp it back in. > Going back and reimporting the data is a last resort, as we'd either > lose or recreate user data that has been entered since the site was > moved on Sunday night. Do you have the redo logs archived since the upgrade? In theory, a clueful Oracle DBA should be able to save a copy of the redo logs in a safe place, re-exp the data from your 8.1.7.4 DB and imp it into a fresh 9.2.0.4 installation, then replay the redo logs -- essentially "recovering" the database, getting all the changes since the upgrade. Of course, this does imply that you're archiving your redo logs and you have all of them since the upgrade. Otherwise, you can do this "the hard way" -- exp the 9.2 DB as it is now, do the re-exp/imp of the old data, then write some scripts to do row-by-row comparison of all the tables. Any row that differs EXCEPT by any ?'s, is a more recent row -- update the DB with the row from the 9.2 exp. This is painful, though, and error-prone. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Charset problem
On Jul 19, 2005, at 2:42 PM, Dossy Shiobara wrote: If you had accented characters (octets with the 8th bit set to 1) stored in the database under 8.1.7.4, then there is NO way the character set of the database was US7ASCII. If it was, then when the data was stored it would have been transcoded to ?'s. Yes way! :) I've verified it myself. Plus someone sent me this snippet from Metalink, which was posted by Oracle Support in response to someone with a similar problem: "It is possible that conversion occured, depending on your data. US7ASCII is a 7-bit character set and it was only supported to use 7-bit characters, however, if 8-bit characters were entered into the database they would be stored (a common example would be the use of accent marks). This would cause conversion as defined by the NLS_LANG parameter. To avoid this, you need to set the NLS_LANG parameter to the target database value of: AMERICAN_AMERICA.WE8ISO8859P1 before starting EXP/IMP." So that's the step I skipped. It makes no sense to me - since imp reports that it is using WE8ISO8859P1 and there will be "possible data conversion" I would think that it would have worked, but apparently not. You will need to re-exp the data setting NLS_CHARSET to WE8ISO8859P1 before doing the exp. Then, imp it back in. I have now been told every possible variation on what to set NLS_LANG to for each step. :) I haven't figured out which of the variations actually works. janine -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Charset problem
On Tue, Jul 19, 2005 at 05:42:56PM -0400, Dossy Shiobara wrote: > On 2005.07.19, Janine Sisk <[EMAIL PROTECTED]> wrote: > > Now, it seems that the default setting of NLS_CHARACTERSET in 8.1.7.4 > > was US7ASCII and in 9.2.0.4 it's WE8ISO8859P1. Everything I've read > > about this conversion says that since it's going from 7 bit to 8 bit > > there shouldn't be any data problems. Well, hah! :) We didn't spot Only true if the "7 bit" data you already had in the 8i instance really was 7 bit clean. Obviously yours was not. You've probably also made things doubly hard on yourself by blindly moving the data into that 9i instance. > If you had accented characters (octets with the 8th bit set to 1) stored > in the database under 8.1.7.4, then there is NO way the character set of > the database was US7ASCII. If it was, then when the data was stored it > would have been transcoded to ?'s. Wrong. It is entirely possible, maybe even common. If the Oracle client (e.g., AOLserver) and Oracle server both CLAIM to be using the same character set, then Oracle will stick the text into the RDBMS binary verbatim with no character set conversion at all. I'm not sure how to check but I bet that's what you were doing with the old 8i instance. Of course, if the RDBMS is using US7ASCII, that's guaranteed to corrupt any and all non-ASCII data you insert. But often, if you read the data back out using the exact same client and server setup, the exact inverse corruption will occur and you will get the original data back. This is probably the only reason why your content appeared to be ok on the old database... Janine, I don't know the solution to your problem, but there is some relevent info here: http://www.piskorski.com/docs/oracle.html#db_convert I thought there was an old ArsDigita Systems Journal article on fixing exactly this problem, but I can't seem to find it now, so perhaps I'm mis-remembering. These two articles do have some relevent info on character encodings and Oracle, but they are not the article I was thinking of: http://www.eveandersson.com/arsdigita/asj/multilingual/encoding http://dqd.com/~mayoff/encoding-doc.html -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Server not stopping properly
On Mon, Jul 18, 2005 at 08:35:21PM -0400, Dossy Shiobara wrote:
> I've filed RFE #1029889 that will introduce [ns_info shutdownpending] so
> http://aolserver.com/sf/rfe/1029889
Well, that sounds like a good idea, but can't you do that already with
ns_atshutdown if you need to? I've used code like this:
# This runs at AOLserver startup:
if { ![nsv_exists . shutdown_pending] } {
# Got this idea from Rob Mayoff here:
# http://www.arsdigita.com/bboard/q-and-a-fetch-msg?msg%5fid=000Yky
nsv_set . shutdown_pending 0
ns_atshutdown {atp_shutdown}
}
ad_proc atp_shutdown {} {
} {
nsv_set . shutdown_pending 1
# Do more custom shutdown stuff here.
}
--
Andrew Piskorski <[EMAIL PROTECTED]>
http://www.piskorski.com/
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
