About jadair

jadair · ‎07-19-2019

For every choice of semantics for these properties, we found failure scenarios that would result in good values overwriting bad values, either in CM during bootstrap or grow, or in Director's deployment or cluster template during refresh. The blacklist was the least-bad solution. The blacklisting will not result in errors if you provide the properties--they will just be silently ignored when Director passes the configuration to CM. With the blacklists in place, CM becomes the source of truth for these properties, so you will still be able to set them in CM if the autoconfigured values are not acceptable. If for some reason you have problems bootstrapping without them, the bootstrap and update blacklists are separately configurable, so you might be able to provide them at bootstrap. I can't recall what the potential failure scenarios were there.

jadair · ‎07-19-2019

Can you please clarify whether you were already using those custom settings and they are not being applied correctly, or whether you started providing those custom settings as a solution for the problem you raised in this post? If it's the latter, I'm glad you found the custom settings. That was going to be my recommendation. What version of Director are you on? While implementing improvements to the deployment/cluster refresh process in 6.2, we ran into some bugs around those settings getting overwritten during refresh. There is a new blacklist in place to avoid overwriting those properties (so that CMs autoconfigured values don't get smashed), but that could prevent your custom values from taking effect. So if you run into any problems on 6.2 or later, please let us know.

jadair · ‎07-19-2019

According to the comments on the Jira, the properties will not include hikari. That is consistent with the recommendation in the previously linked stackoverflow thread.

jadair · ‎07-19-2019

@Da It turns out that the inability to configure these properties was a Director bug which has been fixed for our upcoming 6.3 release. Once you are on 6.3, you will be able to configure the setting (for the Hikari connection pool, as it turns out) using the spring.datasource.maximumPoolSize property. I am sorry that there is no workaround for earlier releases.

jadair · ‎07-19-2019

We're relying on springboot, and are not doing anything special. I notice that in the application.properties embedded in the jar, some of the documented tomcat properties, like testOnBorrow and validationQuery, are being set with a prefix of spring.datasource.tomcat. Based on that stackoverflow answer, I wouldn't expect that to be required for maxActive, but give it a try and let me know if it works.

jadair · ‎07-19-2019

I can't confirm that your problem is caused by the connection pool size, and have never adjusted the connection pool settings manually, but Director uses spring-boot so you should be able to set the appropriate properties in application.properties as described in this stackoverflow question: https://stackoverflow.com/questions/25573034/spring-boot-how-do-i-set-jdbc-pool-properties-like-maximum-number-of-connection The property prefix should be spring.datasource, and the supported properties should be these: http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html#Common_Attributes For the pool size specifically, you should be able to set it like this: spring.datasource.maxActive=200

jadair · ‎07-18-2019

It would be helpful for us to see the logs. There should be additional info logging for the individual connection attempts ("Attempting connection to <endpoint>").

jadair · ‎07-15-2019

It looks like we failed to update the documentation when we added support for this in 6.2.0. Good catch! The cluster refresher should detect changes to the instance type made in the Azure portal and update the cluster template with the new information. If this results in an instance group being inconsistent (with some instances on the old instance type and some on the new), grow operations will be blocked for the cluster. If the instance group is made consistent (by either changing all the instances to the new instance type, or by shrinking away instances using the old instance type), grow will be enabled, and a subsequent grow operation will use the new instance type.

jadair · ‎04-04-2019

Support for CentOS 7.6 was added in Cloudera Altus Director 6.2, which released today. Altus Director does not validate the CentOS version, but CentOS 7.6 has not been tested with older Altus Director versions.

jadair · ‎06-21-2018

Glad you figured this out. Thanks for posting your solution for other forum users.

Online	Offline
Last Visited	‎08-19-2019 12:16 PM

Member Since	‎10-28-2014 12:50 PM
Last Visited	‎08-19-2019 12:16 PM
Posts	71
Kudos received	11

Cloudera Community

Re: Director Not Increasing Heap of Host Monitor

Re: How to increase database pool for Director?

Re: How to increase database pool for Director?

Re: Azure: Changing instance type post deployment

Re: Cloudera Altus support of CDH on CentOS 7.6

Re: Director Not Increasing Heap of Host Monitor

Re: Director Not Increasing Heap of Host Monitor

Re: How to increase database pool for Director?

Re: How to increase database pool for Director?

Re: How to increase database pool for Director?

Re: How to increase database pool for Director?

Re: Altus Director 6.2: Failure to connect to Azur...

Re: Azure: Changing instance type post deployment

Re: Cloudera Altus support of CDH on CentOS 7.6

Re: Cluster install with Director hangs on KAFKA p...