Symptoms of the problem I'm trying to eventually solve: inconsistent communication through a web browser at port 8085 (the default) from a remote system, and even on localhost sometimes. Typically, manifest as timeouts. I can ping the port remotely through Windows PowerShell. Java exceptions and cryptic activity on the console (cryptic because I'm not, in truth, a server administrator, just a software engineer in a small group)
We've spent almost the whole week just trying to get it to a stable state after install.
Nice formatting. First of all, I highly doubt Bamboo version you use can be 1.6 especially when you say that you're evaluating. The current version (as of writing this post) is 6.8.0.
Coming to the problem: You say that you have intermittent problem in accessing Bamboo UI from a remote machine. This, to me, sounded like a network issue initially. I was going to suggest you to run telnet to check if you can access the port.
telnet yoursite.com 8085
But when you said that it times out even when you access localhost, I assume the issue could be due to some resource crunch. What is the heap limit set in your JVM? You can find it in <bamboo-install>/bin/setenv.sh
I'm sure your <bamboo-home>/logs/atlassian-bamboo.log should hint you with some inputs (not <bamboo-install>).
As you say that you're evaluating our product, I encourage you to reach out to us (Bamboo support) via support.atlassian.com and one of us should be able to assist you.
Thanks! I try to stay human.
That sounds like a great idea (contacting support) because it's pretty hard to troubleshoot when you have no logs to look at (see the blocking issue above).
Telnet does not connect, and I totally mixed the version number of Bamboo up with something else, but you're too smart for me and figured it out anyway.
Yes! I was just telling my coworker that it sounds like a resource is getting quickly choked out but no matter how many hammers I buy it's just not a nail (so I need help from someone in support who can show me how to investigate this).
Question about the cache though: I haven't changed it... why would the installation package be shipped with a cache that's insufficient for just running the program for the first time?
Edit: Disregard. This might be more complicated than shipping with a number that fits all.
About the heap limit: I'm not entirely how to read that from the file. It's a bat file (not sh) because, presumably, I'm on windows, and it looks like that might be set as an argument to the batch file. I've seen on a lot of other support and community posts that people had to fool around with the JVM environment, but it's probably better if someone from support walks me though troubleshooting that so we can watch "live" what happens.
Edit: I *think* what I'm seeing are the env variables being subbed into the parameters in the batch file. I'll investigate that line. Thanks!
Edit, THE FINAL!: I think these are the values you're referring to:
I'm not yet able to resolve the issue. I Doubled those values and it had no effect, and the system it's running on is practically dedicated to it. The install-home log had a couple of eyebrow-raising entries that I could pick out that might have something to do with it:
2019-02-19 10:17:08,523 WARN [C3P0PooledConnectionPoolManager[identityToken->103lg33a11xjxbycgj8vn|2dbece42]-HelperThread-#0] [BasicResourcePool] Having failed to acquire a resource, com.mchange.v2.resourcepool.BasicResourcePool@470fdcd is interrupting all Threads waiting on a resource to check out. Will try again in response to new client requests.
2019-02-19 10:17:08,554 WARN [C3P0PooledConnectionPoolManager[identityToken->103lg33a11xjxbycgj8vn|2dbece42]-HelperThread-#0] [BasicResourcePool] com.mchange.v2.resourcepool.BasicResourcePool$ScatteredAcquireTask@c711e92 -- Acquisition Attempt Failed!!! Clearing pending acquires. While trying to acquire a needed new resource, we failed to succeed more than the maximum number of allowed acquisition attempts (30). Last acquisition attempt exception:
org.h2.jdbc.JdbcSQLException: Database may be already in use: null. Possible solutions: close all other connection(s); use the server mode [90020-194]
THE END RESULT is that our group went hunting internally for advice and discovered another group that holds a site license for Bamboo, so we're going to share resources. This may never be resolved because we're dropping the administration effort locally, which is sad because someone is going to look for an answer and fix their broken vanilla install and get mired like I did, but at least those log entries might lead to a solution.
As an addendum, If you would like to open a support ticket in order to supply a complete log file for your internal purposes I would be happy to supply one. I just don't have the bandwidth at the moment to scrub the log for sensitive information.
Thanks for updating us, Dan. The last error message points that the Database is already open by some other application/client.
Anyway, you may request your colleague to raise a ticket with us via support.atlassian.com with your evaluation SEN if they still face issues.