hivemq illegal state exception - java

I'm trying to develop a hivemq authentication plugin.
I have followed the hivemq guide for creating a project, and I am not doing anything in the plugin itself. I return true immediately.
mosquitto_sub -t hey
When I try to connect with mosquitto_sub using the command above, I get the error below.
INFO - Started HiveMQ 1.4.2 in 1528ms
ERROR - An unexpecteed error occured:
java.lang.IllegalStateException: illegal state during login of client mosq_sub_12248_ahmetce
at com.dcsquare.hivemq.handler.protocol.ConnectMessageHandler.logStatus(ConnectMessageHandler.java:176)
at com.dcsquare.hivemq.handler.protocol.ConnectMessageHandler.processSuccessfulLogin(ConnectMessageHandler.java:114)
This is the code I'm testing with: http://pastie.org/8555786#22-23
Has anyone had a similar error?

This is a regression in the 1.4.x HiveMQ line and is fixed in all HiveMQ versions > 1.4.3. The solution is to upgrade the HiveMQ version to a more recent one. (At the time of this writing, 1.4.3 is the most recent stable version, but hotfix versions are available.)

Related

KeeperErrorCode = Unimplemented with documented versions

I am in the process of upgrading a ton of dependencies to get rid of any known vulnerabilities. One of which was an old zookeeper version as a transient dependency.
So using gradle I substituted the version with the latest zookeeper
substitute module('org.apache.zookeeper:zookeeper') with module('org.apache.zookeeper:zookeeper:3.6.1')
However of course it wasn't that easy and I got this error upon startup
2020-05-08 12:03:53,509 [ERROR] (main) org.apache.curator.x.discovery.details.ServiceDiscoveryImpl - Could not register instances - will try again later
org.apache.zookeeper.KeeperException$UnimplementedException: KeeperErrorCode = Unimplemented for /applications/...
From what I can tell this is because curator(also a transient dependency) is not compatible with that zookeeper version.
After looking here http://curator.apache.org/zk-compatibility.html I take it that curator is not compatible with zk 3.6.x
and so I settled on this which I assumed would work
substitute module('org.apache.zookeeper:zookeeper') with module('org.apache.zookeeper:zookeeper:3.5.7')
substitute module('org.apache.curator:curator-recipes') with module('org.apache.curator:curator-recipes:4.3.0')
substitute module('org.apache.curator:curator-x-discovery') with module('org.apache.curator:curator-x-discovery:4.3.0')
But it doesn't. I get the same UnimplementedException as before even though they should be compatible?
So am I missing something obvious as to why it won't work?
For the sake of it I've run this for both zookeeper and cura
./gradlew -q dependencyInsight -p ./ --dependency zookeeper
and all the versions are correct (4.3.0 for everything cura related and 3.5.7 for zk)
UPDATE:
So I am not sure if this is just chasing smoke or not, but I found some errors in regards to dropwizard
I was running with this dependency
io.dropwizard:dropwizard-core:2.0.9
that will give the UnimplementedException previously mentioned.
however I saw that curator was also implementing dropwizard but on a different version:
https://github.com/apache/curator/blob/apache-curator-4.3.0/pom.xml#L88
So I downgraded my dropwizard to 1.3.7 which gave me some other errors:
2020-05-11 12:46:39,776 [WARN ] (main) org.eclipse.jetty.server.handler.ContextHandler.ROOT - unavailable
java.lang.ArrayStoreException: org.glassfish.jersey.internal.ServiceFinderBinder
and after investigating it looks like dropwizard is using an older version of jersey, so I upgraded that
substitute module('org.glassfish.jersey.ext:jersey-metainf-services') with module('org.glassfish.jersey.ext:jersey-metainf-services:2.30')
substitute module('org.glassfish.jersey.ext:jersey-bean-validation') with module('org.glassfish.jersey.ext:jersey-bean-validation:2.30')
and now I am back to the original UnimplementedException problem.
So not sure if any of that was relevant or not
I don't really feel like the exception aligns with it, but could the issue be my jersey version?
https://github.com/apache/curator/blob/apache-curator-4.3.0/pom.xml#L72
I am using jersey 2.30

Is there workaround for Java11 TLS1.3 supported group handshake issue before 11.0.3

Trying to move my app from java 8 to java 11 faced with exception
"javax.net.ssl.SSLHandshakeException: extension (10) should not be presented in server_hello"
I found that this issue will be fixed in 11.0.3 (eta Q2+ 2019)
JDK 11 SSL Error on valid certificate (working in previous versions)
But, is there fast workaround right now? Maybe I can adjust some settings to get rid of this problem?
PS. I use Spring RestTemplate

Kubernetes "fatal alert: protocol_version" error when creating a Deployment

We're running a kubernetes cluster on the Google Cloud Platform, which creates a Deployment with 8 hazelcast-based replicas. We've had this running fine for over a month, but recently, we started receiving the below error message whenever we try to start our deployment (non-relevant stack frames omitted):
2016-07-15 12:58:02,117 [My-hazelcast.my-deployment-368708980-8v7ig # my-deployment-368708980-8v7ig] ERROR - [10.68.5.3]:5701 [MyProject] [3.6.2] Error executing: GET at: https://kubernetes.default.svc/api/v1/namespaces/default/endpoints/my-service. Cause: Received fatal alert: protocol_version
io.fabric8.kubernetes.client.KubernetesClientException: Error executing: GET at: https://kubernetes.default.svc/api/v1/namespaces/default/endpoints/my-service. Cause: Received fatal alert: protocol_version
at io.fabric8.kubernetes.client.dsl.base.OperationSupport.requestException(OperationSupport.java:272) ~[kubernetes-client-1.3.66.jar:na]
at io.fabric8.kubernetes.client.dsl.base.OperationSupport.handleResponse(OperationSupport.java:205) ~[kubernetes-client-1.3.66.jar:na]
at io.fabric8.kubernetes.client.dsl.base.OperationSupport.handleGet(OperationSupport.java:196) ~[kubernetes-client-1.3.66.jar:na]
at io.fabric8.kubernetes.client.dsl.base.BaseOperation.handleGet(BaseOperation.java:483) ~[kubernetes-client-1.3.66.jar:na]
at io.fabric8.kubernetes.client.dsl.base.BaseOperation.get(BaseOperation.java:108) ~[kubernetes-client-1.3.66.jar:na]
at com.noctarius.hazelcast.kubernetes.ServiceEndpointResolver.resolve(ServiceEndpointResolver.java:62) ~[hazelcast-kubernetes-discovery-0.9.2.jar:na]
at com.noctarius.hazelcast.kubernetes.HazelcastKubernetesDiscoveryStrategy.discoverNodes(HazelcastKubernetesDiscoveryStrategy.java:74) ~[hazelcast-kubernetes-discovery-0.9.2.jar:na]
at com.hazelcast.spi.discovery.impl.DefaultDiscoveryService.discoverNodes(DefaultDiscoveryService.java:74) ~[hazelcast-all-3.6.2.jar:3.6.2]
....
Caused by: javax.net.ssl.SSLException: Received fatal alert: protocol_version
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) ~[na:1.7.0_95]
at sun.security.ssl.Alerts.getSSLException(Alerts.java:154) ~[na:1.7.0_95]
at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1991) ~[na:1.7.0_95]
...
at io.fabric8.kubernetes.client.dsl.base.OperationSupport.handleResponse(OperationSupport.java:203) ~[kubernetes-client-1.3.66.jar:na]
... 18 common frames omitted
When I google this error, I get a lot of hits about TLS protocol version mismatch. Apparently, Java 8 assumes a different TLS protocol version (TLS 1.2) than Java 7 and 6(TLS 1.0). However, all of our containers run the same docker image (based off of the hazelcast/hazelcast:3.6.2 image), which is based off of Java 7, so there should be no protocol version mismatch (and this layer of our image has not changed).
We've tried to revert all of our recent changes in an attempt to resolve this error, to no avail. And frankly, nobody on our team has changed anything receltly related to SSL or the Hazelcast Kubernetes discovery mechanism. We recently updated our google cloud SDK components (gcloud components update) at the urging of the Cloud SDK tools ("Updates are available for some Cloud SDK components."). We're now running Google Clouds SDK version 117.0.0, but I don't see any breaking changes related to SSL or TLS in the release notes.
Why would we suddenly start seeing this "fatal alert: protocol_version" error message in our kubernetes pods, and how can I resolve it?
The initial google searches indicating this was a TLS version error (version 1.0 vs 1.2 incompatibility) turned out to be useful. This answer to a question about a similar SSLException protocol_version error is what pointed me in the right direction.
I got a test container to run, and using kubectl exec my-test-pod -i -t -- /bin/bash -il to launch an interactive bash shell into the container, I determined that the Hazelcast discovery service could NOT connect using TLS 1.0, but could using TLS 1.2:
/opt/hazelcast# curl -k --tlsv1.0 https://kubernetes.default.svc/api/v1/namespaces/default/endpoints/my-service
curl: (35) error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
/opt/hazelcast# curl -k --tlsv1.2 https://kubernetes.default.svc/api/v1/namespaces/default/endpoints/my-service
Unauthorized # <-- Unauthorized is expected, as I didn't specify a user/passwd.
I am still not sure what exactly changed, possibly a layer of a public Docker container we use, possibly something within Google cloud service (Java 7 is End of Life, after all), and the fine folks at Hazelcast suggested perhaps the REST API had been updated. But evidently something changed that was causing the discovery service expect clients to TLS version 1.2.
The solution was to download the Hazelcast Docker image we were using, and tweak it to use Java 8 instead of Java 7, and then rebuild the image in our own development sandbox:
$ pwd
/home/jdoe/devel/hazelcast-docker-3.6.2/hazelcast-oss
$ head -n3 Dockerfile
FROM java:8
ENV HZ_VERSION 3.6.2
ENV HZ_HOME /opt/hazelcast/
Voila! Our Deployment is running again.

Coldfusion site stopped working after updating JRE1.6->JRE1.7

I am getting
"Information","localhost-startStop-1","04/09/15","10:13:36",,"ColdFusion started"
"Error","localhost-startStop-2","04/09/15","10:13:48",,"The Cron service is not available. This exception is usually caused by service startup failure. Check your server configuration."
after updating from x64 JRE1.6 to x64 JRE1.7u25
My neo-cron.xml isn't damaged and all works hen I switch back to 1.6
I'm on Coldfusion 9,0,1,274733 Enterprise
Any ideas?
Patch your system up-to-date using the Unofficial Updater and it should work again:
http://www.uu-2.info/

While configuring svn in eclipse, svn:PROPFIND /DemoWeb// 405 method not allowed (http://localhost:8080)

I found some question on the same error but I did not get the correct answer. That's why I am posting here my quest. My configurations are:
IDE:Eclipse-kepler
SVN Connector:SVN Kit 1.3.5
JDK: JDK1.6
While configuring below error is occurring.Thank you

Categories

Resources