 |
 |
Hi Lukasz, Everybody, On 8/24/13 5:55 AM, Lukasz Janyst wrote: > Yes, in fact the username "trick" to trigger the new connections would still > work with the new client and that's likely what is happening here. Hmmh ... why do you call it a trick? And where are the usernames coming from? This is all running within a single xrootd-proxy process ... so it is always the same user, I don't see how this could change in any way. (On server side and in monitoring, this is obviously a different user, as port number is also combined into it.) Anyway ... this seems a really bad idea for the proxy :) Here is a dump of server/monitoring-side usernames for a bunch of consecutive file-close events. You can see some of them get reused ... but 105 of such connections stayed for 3 days+ (after reading ~300 files with 300 XrdCls in a single process). * 413974 * alja.2636:[log in to unmask] * * 415017 * alja.2636:[log in to unmask] * * 416011 * alja.2636:[log in to unmask] * * 416476 * alja.2636:[log in to unmask] * * 417680 * alja.2636:[log in to unmask] * * 419305 * alja.2636:[log in to unmask] * * 419376 * alja.2636:[log in to unmask] * * 419520 * alja.2636:[log in to unmask] * * 419599 * alja.2636:[log in to unmask] * * 419942 * alja.2636:[log in to unmask] * * 420628 * alja.2636:[log in to unmask] * * 421065 * alja.2636:[log in to unmask] * * 422202 * alja.2636:[log in to unmask] * * 422688 * alja.2636:[log in to unmask] * * 423059 * alja.2636:[log in to unmask] * * 423080 * alja.2636:[log in to unmask] * * 424121 * alja.2636:[log in to unmask] * * 424264 * alja.2636:[log in to unmask] * * 431576 * alja.2636:[log in to unmask] * * 488603 * alja.2636:[log in to unmask] * * 489027 * alja.2636:[log in to unmask] * * 489340 * alja.2636:[log in to unmask] * * 494316 * alja.2636:[log in to unmask] * * 494699 * alja.2636:[log in to unmask] * * 496100 * alja.2636:[log in to unmask] * > In fact you can see what is exactly happening if you set the XRD_LOGLEVEL and > XRD_LOGFILE envvars as described in the xrdcopy man page. Alja will run our test with this on ... but whatever the outcome, these connections should still be closed at some point. Andy, can you please comment on this? [Does anybody know, is Andy away ... or I should kick his chair in a separate email?] Cheers, Matevz > Cheers, > Lukasz > > On 23.08.2013 21:58, Fabrizio Furano wrote: >> Hi guys, >> >> you are reminding to me a historical thing with this thread. You may >> want to doublecheck these two points, and see if the defaults or the >> behavior is appropriate to the behavior of your proxy: >> >> - by choice the connections to the redirectors had a very long TTL, >> one day if I remember correctly >> - at some point, due to some interaction with the sec (don't remember >> exactly what by now) the behavior was changed to having one physical >> connection per process per user. Maybe Gerri remembers the rationale of >> this better than me. My point is to raise that if one sees many phyconns >> from the same process, they could be linked to different user ids. Worth >> checking IMHO. >> >> Hope that helps. >> >> Cheers >> Fabrizio >> >> >> >> >> On 8/23/13 9:42 PM, Brian Bockelman wrote: >>> On Aug 23, 2013, at 2:05 PM, Alja Mrak Tadel <[log in to unmask]> wrote: >>> >>>>>> normally XrdCl would open one connection per server it contacts. >>>>>> Not per file. >>>>> >>>>> OK, how do we get 105 connections from a single process to the >>>>> meta-manager then? :) >>>> >>>> >>>> FYI:: The connections listed with netstat are to the origin >>>> xrootd.unl.edu. >>>> >>> >>> Hi, >>> >>> So - we see duplicate connections to the redirector, but no duplicate >>> connections to the data server? >>> >>> Could be a client bug, of course! >>> >>> Brian >>> ######################################################################## >>> Use REPLY-ALL to reply to list >>> >>> To unsubscribe from the XROOTD-DEV list, click the following link: >>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1 >>> >> > ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1