I have the set of Liquibase scripts which recently got migrated from 2.0.1 to 3.5.3. Scripts which were running in 25 mins in 2.0.1 is taking about 1 hr 55 mins to execute in 3.5.3. We cannot afford this increase in time.
Any help is highly appreciated?
Thanks
Manohar
In order to get a handle on this, it would be essential to have some profiling information. Ideally, you would run the 2.0.1 and the 3.5.3 code using the YourKit java profiler, collect the performance snapshots they produce, and then submit that to the Liquibase bug system for analysis.
Related
We use Logi info studio for reporting purposes. we are right now using Logi info version 12.6. prior to this version we were using 14.1 and we had to roll back as we had many issues with it. The problem here was we never roll back the scheduler versio when we roll back the version on logi info studio. we sorted that out by rolling the scheduler version as well. But we are facing errors when we schedule reports. the error pasted above is a generic error and i am havng a hard time why the reports are falling if the version of the scheduler is compatibler with the version on logi infoAny . To make sure the reports do not timeout i increased the timeout time that can be specified in the -settngs file. What i need help on is a guidance to where i should look for an error that is less generic than the one we are gertting or anything that can fix the issue.
I made the version of the scheduler and the version of log info compatible . Also i increased the timeout as the reports that we are running are rather larger reports and i wanted to make sure this reports are not just failling just because it is timing out.
How do I change the table version via the Hudi CLI?
Steps:
ssh into EMR
kick off the hudi cli /usr/lib/hudi/cli/bin/hudi-cli.sh. Version of the Hudi CLI is 1.
connect to my table connect --path s3://bucket/db/table
In the desc of the table I see that it is version=3, but I want to use Hudi 0.9.0 to write to the table so I would like to set the table to version=2.
org.apache.hudi.exception.HoodieException: Unknown versionCode:3
at org.apache.hudi.common.table.HoodieTableVersion.lambda$versionFromCode$1(HoodieTableVersion.java:54)
at java.util.Optional.orElseThrow(Optional.java:290)
at org.apache.hudi.common.table.HoodieTableVersion.versionFromCode(HoodieTableVersion.java:54)
at org.apache.hudi.common.table.HoodieTableConfig.getTableVersion(HoodieTableConfig.java:246)
Sadly, I'm not aware of any way to use version 0.9.0 to downgrade 3 to 2, due to the error you are getting. There is no way for version 0.9.0 to know how 0.10.0 was writing things differently.
Recently, AWS has 6.6 available for use, but it isn't well documented. I'd recommend switching over to that, because it has hudi version 0.10.0 and can then do that downgrade.
This link should get updated whenever 6.6 gets updated in the docs.
https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-release-app-versions-6.x.html
Side note, if you are using the bootstrap action script provided by AWS to repair the log4j vulnerability, I'd recommend taking the version 6.5 version provided and editing it to be 6.6. There is not a 6.6 script available at this time, but I did that and was not able to detect any vulnerabilities.
This link provides an explanation on the bootstrap action:
https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-log4j-vulnerability.html
We are upgrading Our Cloudera Hive from 1.3 to 2.0, Could you please let us know, if there is known issues related to this, i did a search in Tableau and Cloudera Community, but i didn't found any issues.
Unless there is something on the Known Issues page then in general there should be no problems.
If you are concerned, then I would strongly suggest upgrading a test database instance from 1.3 to 2.0, and then confirming your exact 10.3 version of Tableau can connect to this new version without any issues. If any issues are experienced, then please contact Tableau Technical Support and they will assist you with next steps.
We managed to migrate our system into Hybris 6.7
System update took around 5 hours
Was this due to the migration, or is this the expected duration after each deployment?
Could this be enhanced by any mean?
Thanks
I think it take once for first upgrade because of type system changes. Did you try and logging it in your pre-prod system? You can check steps elapsed times in logs/screens.
Subversion is very slow in IDEA 10.5, It always refresh Subversion history after update java source or commit, every refresh Subversion history about cost 30 seconds，but in Eclipse,Subversion is very fast
What OS are you running? I've seen some problems with 64 bit only Linux kernels and jsvn earlier.
There can be multiple reason,
Subversion repository connectivity can be very slow or may have huge network traffic.
It can be also caused by insufficient performance of your computer.
As far as I know there know intelij Idea 10.5 related issues with subversion. Any way try 11.0.1 it is more stable and more features compared to 10.5
Regards
Isuru