# Secure properties: username, password, keyFile are specified in ~/.m2/settings.xml # For testing we're using billiards and tscc. In production we currently only # use tscc (via sftp/ssl). Contrary to what you'd expect if you have maxconn = 0 # here, SSLConnectionPool will hardcode it to 10. In cipres-dev.properties I have # a connection pool size of 10 for submitJobD and loadResultsD so I can end up # needing more than 10 connections, I think. billiards.host=billiards.sdsc.edu billiards.username=${billiards.username} billiards.password=${billiards.password} billiards.minconn=0 billiards.maxconn=${ssl.maxconn} billiards.end snooker.host=snooker.sdsc.edu snooker.username=${snooker.username} snooker.password=${snooker.password} snooker.minconn=0 snooker.maxconn=${ssl.maxconn} snooker.end # triton.host=triton-login.sdsc.edu triton.host=tscc-login.sdsc.edu triton.username=${triton.username} triton.keyFile=${triton.keyFile} triton.minconn=0 triton.maxconn=${ssl.maxconn} triton.end # Oct/2013: use tscc-login.sdsc.edu round robins between two nodes. # Unfortunately, there's a significant delay after you make mods to files via # one node before it's visible on the other, so we have to use the same node # to stage a job and then run it. I just picked tscc-login2 since it doesn't # matter which we use. tscc.host=tscc-login2.sdsc.edu tscc.username=${triton.username} tscc.keyFile=${triton.keyFile} tscc.minconn=0 tscc.maxconn=${ssl.maxconn} tscc.end