We encounter an error when we go from 2.7.2 et 3.0.4 MariaDB JDBC driver with setFetchSize(Integer.MIN_VALUE)
java.sql.SQLSyntaxErrorException: (conn=27489500) invalid fetch size
So we switch to setFetchSize(1)
https://mariadb.com/kb/en/about-mariadb-connector-j/
Before version 1.4.0, the only accepted value for fetch size was
Statement.setFetchSize(Integer.MIN_VALUE) (equivalent to
Statement.setFetchSize(1)). This value is still accepted for
compatilibity reasons but rather use Statement.setFetchSize(1), since
according to JDBC the value must be >= 0.
And I found nothing in the release notes.
This is a connector or idea bug, you need to downgrade.
I have the same problem, on the datagrid, searching the forums, the recommended solution is to reduce the version until the fix is released.
Ref: https://youtrack.jetbrains.com/issue/DBE-16376
Related
when I tested my smart contract in Kovan, the oracle (0xc57B33452b4F7BB189bB5AfaE9cc4aBa1f7a4FD8) listed in Contract Addresses failed to fulfill my request.
As I checked the failed transaction, I've found out that the signature in the InputData was fulfillOracleRequest2 whereas other successful transactions' InputData contained fulfillOracleRequest. So the root cause of the issue seems to be the discrepancy between ChainlinkClient's version(v0.8) and the oracle's version.
Does anybody know of any oracle compatible with ChainlinkClient v0.8 in Kovan?
I've basically gone through the official tutorial to Use Any API except for the version of ChainlinkClient(The tutorial noted v0.6 but I used v0.8).
By updating #chainlink/contracts from 0.1.7 to 0.2.1 (and by adjusting the path to ChainlinkClient.sol), my requests started to get fulfilled.
our application was recently upgraded to cassandra datastax driver 4.4.X. Earlier it was on version 3.3. After the upgrade we noticed quite a lot of timeout issues for ex:
init query timeout
session query timeout
control connection timeout..
and other timeout parameters defaulted in reference.conf
Earlier this used to work with default parameter but after the upgrade we need to default this to > 5 seconds.
Have any one faced similar issue after the upgrade?
You need to upgrade to at least Java driver 4.8 (better to 4.9) - previously timeouts were too aggressive (0.5 seconds), in 4.8 it was increased to 5 seconds (by fix of JAVA-2841).
Or you can just override corresponding parameters in the application.conf file.
We have Oracle11gR1 and Oracle18c.
Perl clients(11.7.0.1) have to access to both version so far.
But Oracle client(11.7.0.1) were recommended to upgrade to new one(12.1.0.2)
according to Doc ID 207303.1 - 'Client / Server Interoperability Support Matrix '
I'd like to hava 2 version of DBD:Oracle on the same clinet.
one for 11.7.0.1.
another for 12.1.0.2.
Because We can back to stable one immediately if new one caused problems.
How can I do that?
or
Impossible? Why?
I was successfully to install the following,
oracle-instantclient12.1-devel-12.1.0.2.0-1.i386.rpm
oracle-instantclient12.1-basic-12.1.0.2.0-1.i386.rpm
After re-install DBD::Oracle,V$SESSION_CONNECT_INFO shows them to '12.1.0.2'.that's I expected.
My Question is
How to switch back and force between 2 version of Oracle clinet of DBD::Oracle for just in case.
Because We can back to stable one immediataly if new one caused problems.
Ideally, By changing $ORACLE_HOME or $LD_LIBRARY_PATH could be achieved I hope.
Otherwise, A lot of task will be needed like that changing $ORACLE_HOME or $LD_LIBRARY_PATH and re-complile DBD:Oracle to switch them in everytimes.
Does anyone have good advise?
Thanks in advance.
I am able to connect to Db2 on z/OS with the IBM universal JDBC driver file db2jcc4.jar using IBM JDK 1.8 that is bundled with WebSphere 9. Every thing works fine and I can browse the catalog and execute queries. I used Squirrel SQL version 4.0.0.
But when I switch my JDK to the Open JDK 8 or 12 while keeping everything else the same, I get the following error. What should be done to fix this error? What is the difference between IBM JDK and Open JDK, which causes the DB2 connection to work with one JDK and fail with the other?
Here is one of matching articles of your case:
JDBC application may receive error "Security mechanism not supported"
https://www.ibm.com/support/pages/jdbc-application-may-receive-error-security-mechanism-not-supported
Resolving The Problem
Set the following property :
securityMechanism = ENCRYPTED_USER_PASSWORD_AND_DATA_SECURITY (13)
Alternatively you can set property retryWithAlternativeSecurityMechanism to YES(1).
Hope this helps.
According to IBM's documentation for their IBM Data Server Driver for JDBC and SQLJ, error code -4214 is an "Authorization failed" error -- and you know that much. But you can get more specific information about the problem if you call SQLException.getMessage. I think you may have done that already, but it's not entirely clear.
My semi-educated guess is that you haven't yet followed the configuration steps in IBM's driver documentation in the section "Configuring the Java Runtime Environment to Use SSL":
https://www.ibm.com/support/knowledgecenter/SSEPGG_11.5.0/com.ibm.db2.luw.apdv.java.doc/src/tpc/imjcc_t0054066.html
You'll have to apply some common sense knowledge to those instructions to adapt them for the OpenJDK, and this might not be an IBM supported combination depending on what/how you do it. If you can somehow use the IBMJSSE2 Provider, that'd be nice.
I think Mao and Mustaccio probably have the right ideas, and probably you're just missing the server certificate in your truststore. The instructions linked above walk you through how to configure that.
I noticed that in version 1.4.3 the app/tasks task JSON contains the state field. However, in version 1.1.1 I don't see it.
Is there some config param I need to set so that the state field is retrieved for each task?
Thanks
--John
The latest (and final) 1.1.x release is 1.1.7, and, unfortunately, does not include a parameter to expose this information. You will need to upgrade to a later release of Marathon (1.3.x) to access it.
Perhaps this is helpful: you can specify the query string parameter "?status=running" to cause only running tasks to be returned.