{"push_id":610331819,"size":2,"distinct_size":2,"ref":"refs/heads/2.10","head":"3667d124769647bf1c6448eb017ab0658480042f","before":"a5b60aceac00932fa912d8c63cf6455625ef323c","commits":[{"sha":"ba0fd18fee9688c9ecd2367529e0167cfbd4bfd1","author":{"email":"6f9af0692a7d1f914f468ec8416a8e6aa93178b4@gmail.com","name":"Gerd Behrmann"},"message":"srm: Use more sensible default values\n\nBased on recent reports, it is clear that too many sites rely on\ndefaults that are not sensible for most of our customers. This\npatch adjusts those defaults.\n\n-srm.limits.jetty-connector.backlog = 1024\n+srm.limits.jetty-connector.backlog = 2048\n\nTo avoid rejected connections upon request bursts (particular\nrelevant for VOs that use SRM from worker nodes). An even higher\nbacklog may be relevant, but 2048 appears to be the default limit\nin the Linux kernel.\n\nIt is generally better to have a connection queue in the backlog\nthat in Jetty: If the client decides to disconnect, we haven't\nspent resources on authentication nor have we created any SRM\nrequest on behalf of the client.\n\n-srm.request.threads = 250\n+srm.request.threads = 12\n\nWith the exception of copy and ls (for which this setting does not\napply), request processing is asynchronous. There is no need for 250\nthreads for that.\n\n-srm.request.ls.threads = ${srm.request.threads}\n+srm.request.ls.threads = ${srm.request.ls.max-in-progress}\n\nMake the default match the documentation (ls is processed\nin a blocking fashion, so we need a thread for each in progress\nrequest).\n\n-srm.request.max-requests = 10000\n+srm.request.max-requests = 50000\n\nIt would be nice if we could control the load on dCache by stearing\nthe number of TURLs, but most users check out TURLs ahead of time\nor forget to release the TURLs. Thus the number of requests allowed\nhas to be much higher than the expected number of concurrent transfers.\nWe should probably have per request type defaults, but I don't want\nto change that in a stable release.\n\nThis also brings the max requests in line with the max transfers\nbelow. Thus by default we do not withhold any TURLs (although we\nstill limit the total number of requests - beyond that the client\nwill receive an error).\n\n-srm.request.max-transfers=2000\n+srm.request.max-transfers=50000\n\nSame argument as above.\n\n-srm.persistence.remove-expired-period = 60\n+srm.persistence.remove-expired-period = 600\n\nWe keep requests for 10 days by default. There is no reason to stress\nthe database with delete requests every 60 seconds.\n\n-srm.limits.ls.entries = 1000\n+srm.limits.ls.entries = 10000\n\nThe point of having a limit is to avoid building too large SOAP\nreplies in memory. It should not be a problem to build a reply\nwith 10000 entries on modern systems.\n\n-srm.service.pnfsmanager.timeout = 300\n+srm.service.pnfsmanager.timeout = 120\n\nToo large timeouts mean that the SRM will take longer to recover from errors\nand will appear unresponsive when it is actually another component that is\nto blame. I chose 2 minutes as many clients time out after about that much\ntime. A pnfs manager that has not responded withing 2 minutes is likely in\ntrouble.\n\n-srm.service.spacemanager.timeout=180\n+srm.service.spacemanager.timeout=30\n\nSame argument, but space manage queries are simpler than name space queries\nand a timeout is less critical. If space manager didn't respond within 30\nseconds, then there is something wrong with it.\n\n-srm.protocols.disallowed.get = ${srm.service.loginbroker.family}\n+srm.protocols.disallowed.get = file,${srm.service.loginbroker.family}\n\nUsing SRM to negotiate NFS transfers is a perfectly valid use case. However\nit requires more than just starting an NFS door: The name space needs to\nbe carefully mounted on the client nodes, aligning the path with Chimera.\nIt is far more common that sites accidentally expose file when starting\nan NFS door and shooting themselves in the foot than sites actually wanting\nto use file with SRM. Thus we block file by default and require the admin\nto manually allow it (making it a deliberate choice).OB\n\n-srm.protocols.disallowed.put = http,${srm.service.loginbroker.family}\n+srm.protocols.disallowed.put = http,file,${srm.service.loginbroker.family}\n\nSame argument.\n\n # ---- Login broker lookup timeout after which a request is retried (seconds)\n (forbidden)srm.lookup.timeout = Use srm.protocols.loginbroker.timeout\n-srm.protocols.loginbroker.timeout = 300\n+srm.protocols.loginbroker.timeout = 20\n\nSimilar to above. If loginbroker fails to respond within 20 seconds, something\nis wrong.\n\nSince we observe problems at sites with our current defaults, I request this\nto be backported to stable branches.\n\nTarget: trunk\nRequest: 2.12\nRequest: 2.11\nRequest: 2.10\nRequire-notes: yes\nRequire-book: yes\nAcked-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>\nAcked-by: Paul Millar <paul.millar@desy.de>\nPatch: https://rb.dcache.org/r/7979/\n(cherry picked from commit da69ddab82d03fd2cc7a22f93610f5267db9279c)","distinct":true,"url":"https://api.github.com/repos/dCache/dcache/commits/ba0fd18fee9688c9ecd2367529e0167cfbd4bfd1"},{"sha":"3667d124769647bf1c6448eb017ab0658480042f","author":{"email":"e260d3bce7ebdf2b872b611fd23ca302a2bc8a49@desy.de","name":"Paul Millar"},"message":"Merge pull request #1407 from gbehrmann/fix/2.10/rb7979\n\nsrm: Use more sensible default values","distinct":true,"url":"https://api.github.com/repos/dCache/dcache/commits/3667d124769647bf1c6448eb017ab0658480042f"}]}