Dnia 29-11-2008 o godz. 19:12 Jim Idle napisa�(a):
On Fri, 2008-11-28 at 09:26 +0100, Pawel (privately) wrote:We are trying, but I think that there are two, completely separate Temenos divisions: one for banking products and the other one jBASE related. They seem not to cooperate well (means share tickets) and banking industry is forced to communicate via "Temenos banking helpdesk". It is a little annoying, when you just see closure attemps of your ticket.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.
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....bash-2.05b$ SHOW-ITEM-LOCKS Polling 772 ports ... PORT PID FILENAME RECORDKEY LOCK# PORT/-PID700 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?
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).
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.
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.Where information about locks is stored? (when jRLA is used) Some shared memory segment?
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.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.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").
Reported and still figthing with helpdesk to avoid closure of it.This does seem like a bug doesn't it.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)
I have exaggerated a little bit. I just observed some UTF-8 CONVERSION FAILED errors. They can make you crying (it seems that ocassionally they treat "binary string" as UTF-8, which fails).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.5. Internationalization is a big pain, not benefit.
Kind regards
Pawel
PS. Merry christmats to group members! :)
----------------------------------------------------
Wygraj 5000 z�!
Wy�lij SMS o tre�ci: WSF.W1002 na numer 7101, koszt 1,22 PLN z VAT.
G�osujesz na serwis 1944.wp.pl w kategorii Kultura: serwis roku.
http://klik.wp.pl/?adr=http://www.webstarfestival.pl/glosuj.php&sid=572
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
