We are running the standalone version of Saiku 2.6. Since upgrading our server to MySQL 5.7 most queries that we run in Saiku (unless they are very basic) stall out and throw the following error:
OutOfMemoryError: Java heap space
Is anyone aware of compatibility issues with older versions of Saiku with MySQL 5.7? Is there anything else that might cause this issue?
Related
I use MySQL for my work and MySQL Workbench as my GUI tool.
But now I am unable to retrieve my databases / tables even with a simple query and the application is crashing while running the queries.
MySQL Workbench Product Version: 8.0.32
MySQL Server Version: 8.0.27
OS: Ventura 13.1 (22C65)
Chip: Apple M1
Problem Report for MYSQL Workbench
I have tried on so many methodologies (which is irrelevant) and finally I have re-installed MySQL Workbench 8.0.31 and now it is working fine without crashing.
I assume this is a problem related with MacOS and MySQL Workbench 8.0.32
I didn't find any relation to the MySQL Server Version on this matter.
Simply download MySQL Workbench 8.0.31 on
https://downloads.mysql.com/archives/workbench/
Please advice if there is any better solution as well.
Thank you.
While trying to connect Dbeaver to Vertica, I keep getting the below error:
//
Can't create driver instance
Error creating driver 'Vertica' instance.
Most likely required jar files are missing.
You should configure jars in driver settings.
Reason: can't load driver class 'com.vertica.jdbc.Driver'
Error creating driver 'Vertica' instance.
Most likely required jar files are missing.
You should configure jars in driver settings.
Reason: can't load driver class 'com.vertica.jdbc.Driver'
ExceptionInInitializerError
java.lang.ExceptionInInitializerError
Index 1 out of bounds for length 1
Index 1 out of bounds for length 1
//
I tried using different JDBC drivers versions but the error remains the same.
I am using MacBookPro with M1 Pro.
I would appreciate any pointers to solve this issue.
I work on the Client Drivers team at Vertica. The problem most likely has to do with the JVM on your M1 macbook. If you try java -version do you get a number like 1.7.0_261 or 17? An M1 macbook will have the open JDK and you will have the simpler version numbering scheme. The Vertica JDBC driver has a bug and does not work with the newer style of version numbers used by JVMs like the one for the open JDK.
As a work around, if you can get a JVM that uses the 1.7 style versioning, that should prevent this from happening. It may be that the Open JDK is the only JVM you can use.
We have also fixed the issue in our latest driver code and plan to release it in our next release, which is due out in a few months. Our drivers are backwards compatible with older versions of Vertica, so you will be able to use the new driver without updating the Vertica server. See Vertica Client Drivers
Lastly, if your organization has a Vertica support plan, you can submit a support request on this issue. You will get notified when there is a driver you can download that resolves the issue.
We are observing frequent crashes of our Production JVM which runs webMethods v9.12.
After analyzing the crash dumps, we came to conclusion that the reason could be some of the libraries in Tuxedo 12.1.1.0 Client because the crash dump mentioned that the problematic frame was in libwsc.so.71.
To give a history of the issue, the problem of Crash was existing from long time when we were running older version of webMethods (8.2) on JVM 1.6. When we were installing the same, we observed these frequent crashes with Tuxedo 8.x. So, up on advice from our Tuxedo Server Ops Team, we upgraded the Tuxedo client to 12.1.1.0 which reduced the number of crashes considerably.
However, now after upgrading to version 9.12, we are observing the issue of frequent crashes again.
Before Upgrade:
Java Version: 1.6.0_27
Tuxedo: 12.1.1.0
After Upgrade:
Java Version: 1.8.0_151
Tuxedo: 12.1.1.0
Please find sample crash file here
Appreciate any pointers to resolve these crash issues.
I suggest you to report this issue on https://support.oracle.com/ and try to get some help there. I've reported several Tuxedo issues there myself and got fixes or workarounds.
I think StackOverflow is a bad place for asking such questions about Oracle's proprietary software. Programming, configuration - yes, crashes - no/
My customer has an existing coldfusion server version 5.x running on windows 2003. They would like to upgrade it to windows 2008/12. We are new to coldfusion, hence want to understand if coldfusion 5.x is supported on 2008/12. If not what should be our migration strategy to upgrade to coldfusion 10.x. Stepped or one shot.
Appreciate your time, thanks in advance.
I'm using Grails 2.0. I used to develop under Grails 1.3.7 but when running an application under Grails 2.0 the performance is very slow. A page can take more than 30 seconds to show and it's very embarrassing and unproductive.
I googled and I found that GSPs in 2.0 are in some cases 10 times slower than 1.3.7 ;
Greame explained that there is a new way of handling GSPs in dev mod, but when executing grails prod run-app I have almost the same problem.
What should I do to speed up development process ? I'm loosing too much time.
PS : My GRAILS_OPTS are "-server -Xmx600M -Xms600M -XX:MaxPermSize=250m -Dfile.encoding=UTF-8 -Dserver.port=9090"
I posted an small announcement on the mailing list about 20 minutes ago:
http://grails.1312388.n4.nabble.com/GSP-Compilation-tt4632864.html#a4635595
This issue was fixed:
http://jira.grails.org/browse/GRAILS-9423
Please test the performance of the latest 2.1.x snapshot build.
Try these
export GRAILS_OPTS="-server -noverify -XX:PermSize=256m
-XX:MaxPermSize=256m -Xmx600M -Xms600m -XX:+UseParallelGC -Djava.net.preferIPv4Stack=true
-Dsun.reflect.inflationThreshold=100000"
For me, the trick was to set Xmx and Xms to the same value and set the PermSize and MaxPermSize to the same value. sun.reflect.inflationThreshold helps with the permgen. (http://jira.grails.org/browse/GRAILS-7878?focusedCommentId=66447&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-66447 in the Grails jira for the explanation)
btw. I filed this issue 10 mins ago:
http://jira.grails.org/browse/GRAILS-9444
If it's interesting, please vote on the issue.
Grails 2.x is slower than 1.3.x for development mode because of the reloading improvements. It uses Spring-Loaded reloading agent that is similar to JRebel.
Make sure that your development laptop has enough memory (>4GB), a SSD and a fast i7 CPU.
Get a recent laptop with 16GB memory & a fast SSD and you won't be thinking of slowness anymore. I'd also recommend a i7 series CPU. That costs only about $1200 currently.
To make sure you are using the latest fixes to the Spring-Loaded reloading agent, use Grails 2.1.x instead of Grails 2.0.x . For Grails 2.1.1 you might want to upgrade the Spring-Loaded reloading agent to a snapshot version.
You can get the latest snapshot from:
https://repo.springsource.org/snapshot/com/springsource/springloaded/springloaded-core/
Currently it's https://repo.springsource.org/snapshot/com/springsource/springloaded/springloaded-core/1.1.1.BUILD-SNAPSHOT/springloaded-core-1.1.1.BUILD-20120821.173635-2.jar .
Replace $GRAILS_HOME/lib/com.springsource.springloaded/springloaded-core/jars/springloaded-core-1.0.6.jar with the downloaded snapshot (rename the snapshot to the same file name springloaded-core-1.0.6.jar).
This answer will be outdated as soon as springloaded-core version 1.1.1 gets released.