VOMRS <---> Voms-Admin convergence check-point meeting 9 December 2008 


Notes by Maria 
Last update 2008-12-16

Attendance
----------
Andrea, Eva D., Gabriele, Ted (Hesselroth), Maria, Miguel A. Steve, 
Tanya, Vincenzo. 

Apologies: Dimitar

1. VOMS code issues causing a strain on the Oracle db servers

It is impossible to explain why the Oracle account LCG_VOMS_TEST_W showed 40K db sessions in week 49 although the VO has no activity at all and hardly any members, wherelse LCG_VOMS_CMS_W which is very populated and busy only showed 4K sessions that week.

Action: Steve will switch off the test VO monitoring to see if figures drop. (if the action is done, then the effect is zero because we have 30K for LCG_VOMS_TEST_W as opposed to 3K for LCG_VOMS_CMS_W (still 10 times more) in this week's report.

Action: Andrea will monitor load on the CNAF Oracle servers caused by the test VOMS installation there. Information provided by Miguel A.:

LCG db usage for the week preceeding our meeting

Sql most done by VOMS:
select vomsca0_.cid as cid3_, vomsca0_.ca as ca3_, vomsca0_.cadescr as cadescr3_ from ca vomsca0_ where vomsca0_.ca=:1

Difference between Oracle accounts (suffix according to privileges).

2. Status of the CERN-CNAF VOMS replication set-up

Barbara Martelli suggested Andrea to use a monitoring tool that measures the load on the CNAF Oracle db.

Action: Steve will run the scripts used for bug fixes' testing, in order to generate some intense activity on voms104.cern.ch. Andrea will report on subsequent progress on this.

3. Next meetings and Xmas absences in case of service panic

Holidays:
---------
Gabriele: 17/12-8/1
Tanya:    24/12-4/1
Maria:    26/12-4/1
Steve:    19/12-26/12
Andrea:   19/12-7/1
Vincenzo: 24/12-6/1
CERN VOMS service will be taken care of by Maria & Steve during the CERN shutdown period 20/12-4/1.

Action:Gabriele will launch a call for our next meeting as soon as he receives the answer on our CHEP'09 abstract.

4. Progress on JSPG-related voms-admin development

The nine bugs listed under point 1 in this page are first priority but code won't be ready before March 2009 due to the high priority given to the new glite autorisation service funded by EGEE.

5. Points for the GDB presentation on VOM(R)S convergence on Wednesday 14 January 2009

Action: Maria will send around the slides for comments around 10 January.

6. News on the "Exhausted result set" error debugging.

The problem still appears in production once every 3rd day. Miguel A. suggested the use of CERN HR db "materialised view" so that vomrs doesn't have to contact another database.

Action: Tanya prefers to run more tests to locate the bug rather than stopping the connection to CERN HR db.

A.O.B. on Trustmanager

Input information and Vincenzo's answer: 
This memory leak it well known.  As you state below, it also happens if 
you use the APIs from util-java (trustmanager does not really matter 
here), and it is due to the way the certificates are read from disk into 
memory.

Citing from the VOMS User Guide (page 95):
--------------------------------------------------------------------------
• cleanup
public void cleanup( )
– Description
Cleans up the object. This method MUST be called before disposing of the 
object, on pains of a memory leak.
--------------------------------------------------------------------------

The reason why this is not automatic is the lack of a proper desstructor 
in Java.  finalize does not really work here.

Action: Vincenzo will inform the GUMS people on this. By the time these notes were published Ted submitted GGUS ticket 44704to collaborate with Vincenzo on debugging the problem as the leak is a a different one.