Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optional[Integer[-1]] $pool_max_wait breaks with latest puppet agent (7.29 or 8.5) #418

Open
KoenDierckx opened this issue Feb 29, 2024 · 3 comments · May be fixed by #419
Open

Optional[Integer[-1]] $pool_max_wait breaks with latest puppet agent (7.29 or 8.5) #418

KoenDierckx opened this issue Feb 29, 2024 · 3 comments · May be fixed by #419

Comments

@KoenDierckx
Copy link

Affected Puppet, Ruby, OS and module versions/distributions

  • Puppet: 7.29
  • Ruby: all
  • Distribution: all
  • Module version: all (up to 6.0.0)

How to reproduce (e.g Puppet code you use)

Upgrade puppet agent to the latest version (7.29 or 8.5)
and use this module

What are you seeing

Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, The parameter '$pool_max_wait' must be a literal type, not a Puppet::Pops::Model::AccessExpression (file: /etc/puppetlabs/code/environments/production/external-modules/jira/manifests/init.pp, line: 333, column: 25) (file: /etc/puppetlabs/code/environments/production/manifests/site.pp, line: 3076) on node XXXX

What behaviour did you expect instead

successfull puppet run

Any additional information you'd like to impart

This is the offending line

Optional[Integer[-1]] $pool_max_wait = undef,

It is caused by a "bug" inside of puppet
puppetlabs/puppet#9268

The current Integer min/max setting of -1 for pool_max_wait does not seem very useful anyhow, so perhaps better to remove the -1, and replace it with 0 like the other parameters

@KoenDierckx KoenDierckx linked a pull request Feb 29, 2024 that will close this issue
@KoenDierckx
Copy link
Author

https://docs.oracle.com/cd/E19879-01/820-4343/abehq/index.html

Max Wait Time: Amount of time the caller (the code requesting a connection) will wait before getting a connection timeout. The default is 60 seconds. A value of zero forces caller to wait indefinitely.

So a minimal value of 0 is the better option anyhow

@alexjfisher
Copy link
Member

But from https://confluence.atlassian.com/adminjiraserver/tuning-database-connections-938846864.html ...

Specifying the value -1 makes Tomcat wait indefinitely.

Maybe JDBC parameters vary between implementations??

@alexjfisher
Copy link
Member

The Jira documentation may have been slightly inaccurate. Looking at the code...

https://github.com/apache/tomcat/blob/6ee4600185945c4c37ff81403c616bf9db3ec34f/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java#L712-L714

If that tomcat function is called with wait set to -1 then the maxWait pool property is used. If that is 0 or less, then it is set to the maximum value of a long integer (something around 300 million years).

So -1 should work, but 0 would too.

But considering how Atlassian documented to use -1 I'd just leave this module as is, and wait for the Puppet release that fixes this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants