I'm using the version 3.8.1 of Vertx with Java 11.05 and I configured the verticles to use Hazelcast.
Everything works fine and the application runs without any issues. However, I begin to receive the error a thread has been blocked on Hazelcast.
I'm checking the error logs for the verticles and there are not blocked threads in the code or any other issues.
The issue only happens when the application is under load test. Also, the issue not seems to affect the services.
The services are responding without any problems.
Does anyone have the same issue before?
Thanks to tsegismont.
I find a solution to this issue. The original conversation is on google forums. But the answer is to upgrade the version of Hazelcast.
The version that solves the issue is 3.11.
I used this POM call for fix the Hazelcast library.
<!-- specify Hazelcast version default 3.10.5 -->
<!-- https://mvnrepository.com/artifact/com.hazelcast/hazelcast -->
<dependency>
<groupId>com.hazelcast</groupId>
<artifactId>hazelcast</artifactId>
<version>3.11.7</version>
</dependency>
If you keep having issues, the problem could be in Hazelcast as something referred to brain split syndrome on the cluster.
https://community.pega.com/knowledgebase/articles/system-administration/split-brain-syndrome-and-cluster-fracturing-faqs
Also, Hazelcast has some specific configuration for the cluster that can help to solve the issue.
Kind regards,
Juan
Related
I use spring-boot-starter-activemq with the lastest version of springboot (2.7.1). Our company's dependency tracker marks activemq-broker which is part of the starter as vulnerable because of CVE-2015-3208 (XML external entity - XXE). We use ActiveMQ instead of Artemis for integration with some legacy system. Is there a way to fix it or is this just a false positive ? I see that that there are updates in maven repository quite frequently (link) hence I can't believe that the vulnerability published in 2017 is not solved yet.
Thank you for your thoughts !
I am trying to update an application which already pulls in the kitchen sink (or perhaps a few, they're joined at the hip) and I am sorting through version conflicts.
I want to update to Spring Boot 2.5+ and also use Spring Cloud Consul - I am attempting to pull in:
spring-cloud-starter-consul-discovery:3.0.3
spring-boot:2.5.4
For bonus points, within spring-cloud-starter-consul-discovery, I am seeing that it pulls in reactor-core:3.4.6 and at the same time reactor-extra:3.4.3 (which pulls in reactor-core:3.4.5). The list goes on and on ...
https://search.maven.org/artifact/org.springframework.cloud/spring-cloud-starter-consul-discovery/3.0.3/jar - original point of contention is that it pulls in spring boot 2.4.6 ... it was advertised as supporting 2.5+, then shouldn't the version reference 2.5+?
https://search.maven.org/artifact/org.springframework.cloud/spring-cloud-loadbalancer/3.0.3/jar - this to me is just plain laziness, right below reactor-core is reactor-extra, why wouldn't the Spring developers make extra pull in the same version of core? See: https://search.maven.org/artifact/io.projectreactor.addons/reactor-extra/3.4.3/jar
While this is a trivial problem to solve, it shouldn't be my problem. Am I missing something, or is this just the way it is and I shouldn't expect more?
First of all, you need to look at this compatibility matrix between cloud and boot dependencies. Then, you need (for example) to generate your bom, where you import
the correct cloud dependencies bom
spring boot dependencies bom
These boms, internally, either import other boms, like for example consul, the one you are interested in, which is at version 2.2.8.RELEASE. Look in the properties tag in that file and see this:
<spring-cloud-consul.version>2.2.8.RELEASE</spring-cloud-consul.version>
specifically:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-consul-dependencies</artifactId>
<version>${spring-cloud-consul.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
You can then look at the specific consul bom and see that the version consul-discovery is:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-consul-discovery</artifactId>
<version>${project.version}</version>
</dependency>
Same pattern to find out what version is where can be done for reactor dependencies.
From my 10 minutes investing into this, I don't see a version of spring-cloud-starter-consul-discovery:3.0.3 that would be included in a cloud-dependecies.
You could still try to force a certain version of a dependency. We just recently had such a problem in spring-cloud-kubernetes, internally.
This may or may not work, though.
We use fabric8-maven-plugin to manage the full lifecycle of all of our kubernetes services. We are having a problem upgrading statefulsets (similar to this post but we dont use the kubernetes-client). The version of the maven plugin is 4.3.1. We have no issues with daemonsets but I just cant find a way to update statefulsets. We get the same error as the afore mentioned post.
Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', and 'updateStrategy' are forbidden..
I have tried to set the updateStrategy to rolling but that doesn't seem to do anything.
Thanks Paul
I'm facing with a frustrating problem with jdbc
org.apache.tomcat.jdbc.pool.PoolExhaustedException: [...] Timeout: Pool empty. Unable to fetch a connection in 30 seconds, none available[size:4; busy:4; idle:0; lastwait:30000]
I found several solutions here about how to fix it but this is not the point.
I'd like to see from the logs WHO is creating these connections and not releasing.
Do you know some spring boot configuration or logback setup to show the event where a jdbc connection is taken from or returned to the pool?
Thanks
If following Paul's recommendation doesn't help, my next step would be to add:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
Then use the /trace and /metrics endpoints to figure out whats happening.
I have a Java GAE application with two modules for which I am having problems using the backup/restore Datastore Admin functionality. The tasks get created properly but fail and retry endlessly in the default queue. From the logs of my non-default ("engine") module it looks like it is trying to process them there (rather than in the default module for the app). I also don't have anything explicitly mapping /_ah/mapreduce in my web.xml for either module, which seems to be the symptom being reported. I don't see any documentation suggesting I need to go and manually configure appengine-mapreduce.jar so I haven't gone down that road yet.
0.1.0.2 - - [07/Jan/2015:08:11:19 -0800] "POST /_ah/mapreduce/kickoffjob_callback/15759222115551DD09797 HTTP/1.1" 404 234 "https://ah-builtin-python-bundle-dot-MYAPP.appspot.com/_ah/datastore_admin/backup.do" "AppEngine-Google; (+http://code.google.com/appengine)" "engine.MYAPP.appspot.com" ms=10713 cpu_ms=22 cpm_usd=0.000026 queue_name=default task_name=50337988952552890461 pending_ms=10702 instance=0 app_engine_release=1.9.17
This did work at one point but I've upgraded quite a bit (moved from backends to modules, moved to HRD, upgraded GAE version to 1.9.2, etc.).
Thanks in advance for any hints or suggestions!
Edit:
So I figured this out. I have two modules in my app (named default and engine). The default task queue is routed to the engine module (formerly a backend) in my queue.xml, rather than ah-builtin-python-bundle.
Adding a new queue in my queue.xml routed to ah-builtin-python-bundle and using that for Datastore Admin fixed the problem.
If you make any changes to the default task queue using queue.xml, in particular the target element, you'll want to create a queue for using the Datastore Admin. Soemthing like:
<queue>
<name>backup</name>
<rate>10/s</rate>
<bucket-size>40</bucket-size>
<max-concurrent-requests>10</max-concurrent-requests>
<target>ah-builtin-python-bundle</target>
</queue>