jBase- issue

[Sesh]

Hi,

 

We had an problem in COB with the following error message.

 

jBASE: Segmentation violation. Aborting
TRANSEND: Error 0
jBASE: /globus/bnk/bnk.run/globuslib/lib455.so.10: Not enough space
Trap from an error message, error message name = SUBROUTINE_CALL_FAIL
DEBUG aborting as background task
Line 123 , Source INIT.SIGN.ON.OFF
jBASE: Segmentation violation. Aborting
jBASE: Segmentation violation. Aborting
jBASE: Segmentation violation. Aborting
TRANSEND: Error 0

 

Can you please send us the solution asap.

 

Regards,

Sesh.

[Jim Idle]

On Wed, 2008-05-28 at 13:46 +0530, Sesh wrote:

Hi,

 

We had an problem in COB with the following error message.

Please read the posting guidelines at: http://groups.google.com/group/jBASE/web/Posting%20Guidelines

Your post lacks a lot of information that might help to diagnose your problem. If you read the poosting guidelines, then you might get more help here.

 

jBASE: Segmentation violation. Aborting
TRANSEND: Error 0
jBASE: /globus/bnk/bnk.run/globuslib/lib455.so.10: Not enough space
Trap from an error message, error message name = SUBROUTINE_CALL_FAIL
DEBUG aborting as background task
Line 123 , Source INIT.SIGN.ON.OFF
jBASE: Segmentation violation. Aborting
jBASE: Segmentation violation. Aborting
jBASE: Segmentation violation. Aborting
TRANSEND: Error 0

Based upon the few things you have supplied, I am guessing that your machine has run out of virtual addressing space for your process, which either means that you have a ulimit problem, or that you have done something like start a T24 transaction (by the way, these are pretty useless as they are subject to file corruption and so on) and have queued up thousands of writes before trying to call TRANSEND.

As this is a back ground task, it might be that your background tasks have not been allocated enough resources.

However, it seems that you also have at least 455 shared libraries. What size have you made these via the jlibdefiniton file? A smaller number of larger libraries is best in general.

The fact that the not enough space message happens and the process then tries to carry on because of the DEBUG trap is a jBASE bug. Something is trying to allocate memory and not checking that it was actually allocated the memory.

In rough order of likelihood:

1) ulimits for background processing;
2) Poor application programming;
3) Not enough swap space allocated to a system that reserves the swap space even though it does not use it (HPSUX does this by default for instance);
4) See 2)
5) Poor T24 core application programming (actually this might be more likely than #5).

Jim

[John Watson]

Hi Jim,

You wrote;

'that you have done something like start a T24 transaction (by the

way, these are pretty useless as they are subject to file corruption

and so on)'

Now here you could be saying that a T24 transaction is rubbish which
is a point of view and each to their own; however you could also be
suggesting that there are issues with transaction boundaries.

If your comment does relate to transaction boundaries could you expand
a bit please because this causes me great concern.

Strangely, I am hoping that you are slagging of Temenos here ;-)

Cheers,

John.

[Jim Idle]

On Thu, 2008-05-29 at 01:31 -0700, John Watson wrote:

Hi Jim,

You wrote;

 'that you have done something like start a T24 transaction (by the
way, these are pretty useless as they are subject to file corruption
and so on)'

Now here you could be saying that a T24 transaction is rubbish which
is a point of view and each to their own; however you could also be
suggesting that there are issues with transaction boundaries.

The comment relates to the fact that T24 seems to have 'transactions' whereby it stores the writes and so on in another set of hashed files. Now, this could have changed since last I saw the system but if it is still doing this, then it is VERY prone to error if used for disaster recovery. If used merely at the application level, to store updates before processing a transaction in some way, and these things are abandoned after a system crash, then it is rather inefficient, but probably is harmless.

The problem is that the more a file is written to, the more likely it is subject to corruption in the event of a hard crash or someone doing something silly like issuing "kill -9". Hence if you store all the writes in one or two files in an attempt to create transaction boundaries at the application level, then these very files are the ones most likely to be corrupt after you restart the system. In the worst possible instance, the file doesn't appear corrupted but some write or other is just missing, which means you think you have recovered the system but have in fact propagated logical inconsistencies. Now that T24 is on jBASE, it should not be implementing any application level transactions as jBASE transactions guarantee an all or nothing commit to the database and only completed transactions will be restored by replaying the journal after a crash.

Obviously, there can be no subjective opinions about transactions and journalling - they either work correctly at the system level, or they don't! :-)

If your comment does relate to transaction boundaries could you expand
a bit please because this causes me great concern.

jBASE transactions and journaling are what you should be using and they have no issues that I know of. 
They are implemented at the correct system level and a crash cannot corrupt the journal such that recovery cannot take place.

Jim

[John Watson]

Phew!

A long time ago in the days on Universe we used to keep a post
transaction image in a JOURNAL file, since G-sometimeago we no longer
do this; instead we use transaction boundaries.

This stuff is all handled internally that when you call the
JOURNAL.UPDATE routine; if you use pre G-old then the JOURNAL file is
used and if you use T24 you use transaction boundaries.

Everything should be ok for our up-to-date readers.

Cheers.

John (slowy putting the valium back on the shelf)