Recently upgraded from Redis version 3 to Redis version 7.0.5 which is deployed on aws cloud.
Now when I try to connect to it using lettuce pool I am getting below exception.
org.springframework.data.redis.RedisSystemException: Unknown redis exception; nested exception is org.springframework.data.redis.connection.PoolException: Could not get a resource from the pool; nested exception is com.lambdaworks.redis.RedisException: java.lang.UnsupportedOperationException
Below are the dependent software versions i am using :
org.springframework.data
spring-data-keyvalue : Version 1.2.7.RELEASE
biz.paluch.redis
lettuce : Version 4.4.5.FINAL
org.springframework.data
spring-data-commons : Version 1.13.7.RELEASE
org.springframework.data
spring-data-redis : Version 1.8.7.RELEASE
Please help to get this sorted as I am stuck here.
Related
I am receiving the below error message while try to connect elastic search with Spark..
Code used --
spark.read.format("org.elasticsearch.spark.sql")
.option("es.nodes", "xxxxx")
.option("es.port", "80")
.option("es.nodes.wan.only", "true")
.option("pushdown", "true")
.option("spark.serializer", "org.apache.spark.serializer.KryoSerializer")
.load("indexname/doc")
Error message
java.lang.ClassNotFoundException: Failed to find data source: org.elasticsearch.spark.sql. Please find packages at http://spark.apache.org/third-party-projects.html
Using
Databricks Runtime Version 7.3 LTS (includes Apache Spark 3.0.1, Scala 2.12)
I have a 2 node OpenStack Mitaka environment consisting of a controller/compute node and a compute node.
I've followed the setup guide to enable instance live migration using LVM block storage. I.e.: There's no shared storage backend, just local LVM block storage.
Using OpenStack Horizon to perform the live migration a success message is displayed, however, the migration is far from successful. This worked pretty much out-of-the-box with our Juno installation. I've exhausted Google and cannot find any other instances of people facing the same problem. I thought it might have been a time synchronisation problem so have set both nodes to UTC. Still the problems persists.
Source machine /var/log/nova/nova-compute.log
2016-08-12 15:56:42.120 2230 ERROR nova.virt.libvirt.driver [req-b71ea7b0-5fa8-4b57-92d2-4edec62135c2 b017d86d1143461a92a267d4b912c104 88c686f09e1b427fb750f5c00716f84e - - -] [instance: 5763b6b6-370c-448c-8e8f-8b71eafaa8f1] Migration operation has aborted
2016-08-12 15:56:42.470 2230 ERROR nova.virt.libvirt.driver [req-b71ea7b0-5fa8-4b57-92d2-4edec62135c2 b017d86d1143461a92a267d4b912c104 88c686f09e1b427fb750f5c00716f84e - - -] [instance: 5763b6b6-370c-448c-8e8f-8b71eafaa8f1] Live Migration failure: internal error: unable to execute QEMU command 'migrate': Migration disabled: failed to allocate shared memory
Target node /var/log/libvirt/libvirtd.log
2016-08-12 15:56:41.864+0000: 2170: error : qemuMonitorJSONGetMigrationStatsReply:2443 : internal error: info migration reply was missing return status
2016-08-12 15:56:41.864+0000: 2170: error : virNetClientProgramDispatchError:177 : Cannot open log file: '/var/log/libvirt/qemu/instance-0000006a.log': Device or resource busy
There are no other events captured in the source or target nova or libvirt logs.
I should also note that I am trying to use qemu+tcp (libvirt listening enabled, default tcp port, no auth) rather than qemu+ssh in order to keep things simple while testing. In fact, I intend to only use qemu+tcp anyway.
Which version of ubuntu did you deploy?
I had the same error with ubuntu 14.04 and mitaka version.
And I figured out that default kernel (3.13) makes this problem.
I upgraded the kernel from 3.13 to 4.40 and this problem is gone now.
I hope my experience help you solve this problem out.
Thanks
I have a REST client code working OK locally in a server but failing to unmarshall JSON into Java when packaged and deployed to Bluemix with same Liberty versión (8.5.5.9). Failing code:
Response response = get("/v0.1/path/" + var + "/path/" + var2);
return response.readEntity(MyClass.class);
In bluemix I get this exception:
2016-05-29T13:32:26.16+0200 [App/0] ERR Caused by:
java.lang.NullPointerException 2016-05-29T13:32:26.16+0200 [App/0]
ERR at
org.apache.cxf.jaxrs.impl.tl.ThreadLocalProviders.getContextResolver(ThreadLocalProviders.java:50)
2016-05-29T13:32:26.16+0200 [App/0] ERR at [internal classes]
2016-05-29T13:32:26.16+0200 [App/0] ERR at
com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider._locateMapperViaProvider(JacksonJsonProvider.java:206)
2016-05-29T13:32:26.16+0200 [App/0] ERR at
com.fasterxml.jackson.jaxrs.base.ProviderBase.locateMapper(ProviderBase.java:853)
2016-05-29T13:32:26.16+0200 [App/0] ERR at
com.fasterxml.jackson.jaxrs.base.ProviderBase.readFrom(ProviderBase.java:764)
2016-05-29T13:32:26.16+0200 [App/0] ERR at
org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromMessageBodyReader(JAXRSUtils.java:1356)
2016-05-29T13:32:26.16+0200 [App/0] ERR ... 13 more
The REST result by the server is OK. In fact, if I get that JSON code as String and use a Jackson mapper to unmarshall it , it works ok, but not if I do it the standard JAX-RS 2.0 client way:
return response.readEntity(MyClass.class);
which will fail with error above.
Edit:
Liberty Versions used:
The build pack wee run locally (JAX-RS 2.0 client requests working OK) is:
(WebSphere Application Server 8.5.5.9/wlp-1.0.12.cl50920160227-1523) on Java HotSpot(TM) 64-Bit Server VM, version 1.8.0_77-b03 (en_US)
The one in BlueMix (JAX-RS 2.0 client requests throwing NPE at CXF class):
(WebSphere Application Server 2016.5.0.0/wlp-1.0.13.20160430-1625) on IBM J9 VM, version pxa6480sr3-20160428_01 (SR3) (en_US)
Thanks for any help
We currently experience the same problem with our application and Liberty Buildpack Version: v2.9-20160519-1249
It must be a problem with the current buildpack version, because we didn't change our application code and it was working fine with previous deployments to Bluemix.
As a workaround you can explicitly specify a previous liberty buildpack version when deploying your app to Bluemix. Either by using the '-b' parameter on the 'cf push' command or by defining the 'buildpack:" property in your manifest.yml file. Have a look at the following links for details:
new-console.ng.bluemix.net/docs/cfapps/byob.html
docs.cloudfoundry.org/devguide/deploy-apps/manifest.html#buildpack
You can find out the name of the liberty buildpacks available either via 'cf buildpacks' command or here: bpversions.mybluemix.net
Unfortunately, even the previous version liberty_for_java_v2_8-20160430-1011 seems to have the problem described in this thread. Only the oldest version available liberty-for-java_v2_3-20151208-1311 from December last year, is not affected by this problem.
So currently, the only option seems to be to deploy your app via:
$ cf push MYAPP -b liberty-for-java_v2_3-20151208-1311
We are aware of this issue and it's being worked through a Support Ticket. Will update when we have more info.
IBM has recommended us to use the OpenSource Liberty build pack. It is based on 8.5.5.9, the same official download version, and also seems to have solved the problem. To do this we use this manifest.yml
buildpack: https://github.com/cloudfoundry/ibm-websphere-liberty-buildpack.git
env:
IBM_JVM_LICENSE: L-PMAA-A3Z8P2
IBM_LIBERTY_LICENSE: L-MCAO-9SYMVC
JBP_CONFIG_IBMJDK: "version: 1.8.+"
Until they fix the issue I like this workaround as allows to make sure the version deployed in BlueMix is the someone as the one we use locally to develop and test.
I am migrating my application from jrockit jdk6 to hotspot jdk6. While building my application using maven, one of my integration test makes the build to hang with below error message:
jgroups.JGroupsCacheManagerPeerProvider,ERROR,Failed to create JGroups Channel, replication will not function. JGroups properties:
${jgroups.cache.config}
java.lang.Exception: JGRP000002: unable to load protocol $ (either with relative - $ - or absolute - org.jgroups.protocols.$ - class name)
at org.jgroups.stack.Configurator.createLayer(Configurator.java:430)
at org.jgroups.stack.Configurator.createProtocols(Configurator.java:397)
Please throw some light!
I am setting up a GlassFish cluster following the guide at http://javadude.wordpress.com/2011/04/25/glassfish-3-1-clustering-tutorial/. I started from fresh installs of GlassFish 3.1.1. I also have the same architecture as in the guide: two nodes with one instance each. The DAS is on node1.
I've tried starting from scratch several times and am able to create the cluster, nodes and instances without issue. I also have the DAS communicating with node2 via SSH. However, each time when I get to the point where I attempt to start instance2 it fails:
$ ./asadmin start-local-instance --node node1 --sync normal instance2
Previous synchronization failed at Feb 23, 2012 2:41:53 PM
Will perform full synchronization.
Removing all cached state for instance instance2.
CLI802 Synchronization failed for directory config, caused by:
javax.xml.bind.JAXBException
- with linked exception:
[java.lang.ClassNotFoundException: com.sun.xml.bind.v2.ContextFactory]
Command start-local-instance failed.
I spent the day Googling and searching GlassFish's Jira, but couldn't find a solution to this issue. I'd very much appreciate any ideas you have on how to solve this problem.
My operating system is CentOS 5.7 and my Java version is 1.6.0_20
Unfortunately my instance directory is empty, I'm assuming because it never started. So there is no log file. I set AS_DEBUG=true but it gives no stack trace. The last debug lines before the error are
Removing all cached state for instance instance2.
Removing: /usr/local/glassfish3_1_1/glassfish/nodes/blade-50/instance2/config
Removing: /usr/local/glassfish3_1_1/glassfish/nodes/blade-50/instance2/applications
Removing: /usr/local/glassfish3_1_1/glassfish/nodes/blade-50/instance2/generated
Removing: /usr/local/glassfish3_1_1/glassfish/nodes/blade-50/instance2/lib
Removing: /usr/local/glassfish3_1_1/glassfish/nodes/blade-50/instance2/docroot
Got exception: javax.xml.bind.JAXBException
Acting on a tip from a user in the Glassfish forum, I learned that Java 1.6.0_20 is an older release of Java that is not supported by Glassfish 3.1.1. I worked with a sysadmin to get Java 1.6.0_31 installed on both nodes of the cluster and that did the trick--both instances start up without errors.