On Sun, 2008-11-30 at 23:06 +0100, Pawel (privately) wrote: > Hello, > > Dnia 29-11-2008 o godz. 19:12 Jim Idle napisał(a): > > On Fri, 2008-11-28 at 09:26 +0100, Pawel (privately) wrote: > > > Hello, > > > > 1. I like jBASE very much for flexibility, but... Please look at > > reported things and tell me wheter I am the only one who says that > jBASE > > 4.1(.5.17) was not tested well.
> > 700 10469516 ../bnk.data/re/FBNK.RE.C007 0000000004420004 > > > 0x0162566b,W --- > > 700 10469516 ../bnk.data/eb/F.JOB.LIS000 163 > > > 0x4fc7fdb7,W --- > > 700 10469516 ../bnk.data/re/FBNK.RE.C007 0000000004420004 > > > 00000000,W 696 > > > I cannot see anything wrong with this per se. Though it seems > to be reporting the same record ID locked twice, the second > one seems like it was just a snapshot. If you repeat the > query, see if this state persists. Also, are these the full > record IDs or are they bing truncated. However, why are you > holding so many spooler device locks? > > Presented SIL output was from our PROD server. I think that shown > state of locks was persistent at least for some time. Item names were > not truncated. I am sure that we have 2 snapshots from similar (<5 > min) period of time. (Dead)Lock 700 was there. > > Is jRLA recycling lock information in some periods of time? What > happens if process dies and immediately restarts on _same_ port > number? (eg. 700) Will jRLA think that port 700 still owns locks, > although new process was spawned and lock was/should be released? I > hope that it is not our scenario (I can not imagine any other at the > moment). jRLA periodically (5 minute default, perhaps this shoudl be shorter and you can make it so when you start the jRLA daemon and can also use the jRAL command to tell it to clean up immediately) checks that the UNIX level processes (not jBASE 'port' number) are still alive and if they are not it cleans up the locks. A new process would have a new pid and therefore could not take the lock until jRLA came along and cleaned up the old one. In normal exits, the processes cleans up all locks as it exits. So jRLA is only needed if you core dump or some fool uses kill -9 (see posts passim ad nauseum). You may never be able to track this down unless it happens again a lot. Perhaps you were just viewing it in a state where it was waiting to clean up. Remember to remove the kill command and replace it with a script that checks the signal requested. Make kill -9 a sudo of a killnine script or something similar. > > > > Where information about locks is stored? (when jRLA is used) Some > shared > > memory segment? > > SHOW-ITEM-LOCKS has changed a lot, so I know longer know > whether it is reading directly out of the shared memory > tables, or asking running processes to dump their lock > information into the proc dir. > > I think that PROC contains only information about most recently taken > lock. I may be wrong of course, but I am claiming so after reviewing > "jprocdisp" output and constants. I am very interested in details of > how jRLA is mainting locking information. It is all very technical but there are n groups of p locks in shared memory. Entries consist of process number, inode, filesystem # and so on. There are no bugs in this that I know of. Locks hash in to one of the groups and then scan within the group (should always be a small number). > > 3. SELECTs with simple EVAL (eg. EVAL "@ID[4,10]") on larger tables > will > > bring you to coredump. I suspect that there is memory leak (ulimit > of > > user was "unlimited"). > > Agreed that it is a bug, but a core dump tends to indicate > that the there has been a misuse of memory rather than a > memory leak. > > Whater reason it is - it is little annoying :( You normally test your > programs on smaller tables, but this gives me lesson to test on > PROD-like volumes. Yep. You should have regression tests and unit tests. Developers run small versions but you should run a large tests before release. > > 4. jBASE indexes are a crap. Not because of their performance, but > > simply because they may crash your software (eg. when you are not > > running in I18N mode: create index with locale "C", store some 8bit > > characters in indexed field and finally try to delete (indexed) > record - > > you will get jBASE "UTF8 CONVERSION FAILED" error) > > This does seem like a bug doesn't it. > > Reported and still figthing with helpdesk to avoid closure of it. I don't see why they would want to close it? Jim --~--~---------~--~----~------------~-------~--~----~ Please read the posting guidelines at: http://groups.google.com/group/jBASE/web/Posting%20Guidelines IMPORTANT: Type T24: at the start of the subject line for questions specific to Globus/T24 To post, send email to [email protected] To unsubscribe, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jBASE?hl=en -~----------~----~----~----~------~----~------~--~---
