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.
Can't say any more, but there definitely seem to be more core dumps going on than I personally would like. In the past I have encouraged people to report this to TEMENOS - they need to know about the bugs and I think that they care about this stuff. Most people seem to post here and nothing seems to go to TEMENOS - I think others don't know about this group and so communicate with the help desk and feel that they are on their own. > > 2. jRLA (jBASE component) - look at my SHOW-ITEM-LOCKS report, port 700. > Does it prove that jRLA is buggy? Probably not in fact, but it might tell you that the lock reporting tools are not quite hunky dory. The reporting of held locks, and the state of the actual jRLA tables are not always in sync at anyone time. SHOW-ITEM-LOCKS is using a snapshot of the lock state, to avoid it interfering with performance and so on. > > bash-2.05b$ SHOW-ITEM-LOCKS > Polling 772 ports ... > PORT PID FILENAME RECORDKEY > LOCK# PORT/-PID > ... > 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? > 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. > > 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. > > 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. > > 5. Internationalization is a big pain, not benefit. I18n is pretty easy on jBASE compared to many other systems. However, if you are getting issues with indexing, I can see how it would seem to be getting in your way. Again, make sure that this stuff is reported to TEMENOS - these seem pretty high priority bugs to my mind. 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 -~----------~----~----~----~------~----~------~--~---
