wiki:developers-meeting-20100601
Last modified 11 years ago Last modified on 06/02/10 16:10:57

dCache Tier I meeting June 1, 2010

[part of a series of meetings]

Present

dCache.org(Patrick, Antje, Paul), IN2P3(), Sara(), Triumf(Simon), BNL(), NDGF(), PIC(Gerard), GridKa(Doris), Fermi(), CERN()

Agenda

(see box on the other side)

Site reports

FZK

Happy, everything is fine at FZK.

Triumf

Simon reported that Triumf have tested dCache 1.9.5-19 and it seems to be working fine.

They have upgraded their SRM node to 1.9.5-19 without any incident.

PIC

Gerard reported that things are fine at PIC.

They have upgraded to 1.9.5-20rc1, with tape protection enabled. So far, it is working without any issues. The system is running OK so far, but he will report if there's any problems.

Patrick asked if Gerard tried using the old configuration: with the last column (store-unit) missing?

No, PIC have deployed the stage protection by specifying the store-unit.

BNL

Pedro is just back from a vacation, so he didn't have any problems to report; however, there was one ticket about a p2p issue that was opened whilst he was away.

Other items

FZK kill the doors

Doris reported a problem with dCache and expired certificates. They had deployed 1.9.5-15 on their test system and started lots of clients that ran "srm-cp" copying data into the system overnight. The jobs' proxy certificate expired during the night and the GridFTP doors were rejecting the transfers because of this.

What is interesting is that, after some time, the GridFTP doors died with OutOfMemoryError. They started only 40 jobs, but were seeing some 800 GridFTP connections.

There seems to be two errors here:

  • the SRM was handing out TURLs even though the proxy certificate had expired,
  • expired certificates are not handled correctly in GridFTP doors.

Patrick asked if Doris could try to reproduce the problem with the latest 1.9.5-series release of dCache.

dcap ++

Gerard asked what is the status of dcap++.

Paul explained that the patch is in ReviewBoard, a standard procedure for all changes to dCache and dcap. There are a number of issues with the patch that are being dealt with by the team internally (without involving the patch's developer). Once these issues are resolved then the patch can go into dcap.

Support tickets for discussion

[Items are added here automagically]

DTNM

Same time, next week.