Notes by Maria Last update 2008-12-16 Attendance ---------- Andrea, Eva D., Gabriele, Ted (Hesselroth), Maria, Miguel A. Steve, Tanya, Vincenzo. Apologies: Dimitar
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).
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.
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/1CERN 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.
Action: Tanya prefers to run more tests to locate the bug rather than stopping the connection to CERN HR db.
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.