I am running this vertx application on multi core machine (more than one verticle) and I want to create a singleton instance of PaceRedisConnection. It is creating as many as the number of verticles rather than the single instance
Source code: https://github.com/himanshumps/micronaut-vertx-issue.git
Repository deleted. I created a singleton bean of beancontext and used it in verticle rather can creating a micronaut deployer for vertx verticle
Related
this is my first post on this forum so please go easy on me if a made mistake or else. I'm using spring-boot batch with mongdb and everything works fine but I running in trouble when I have to test my batch. My Batchconfiguration is based on multiple jobs (4 jobs), so
1st trouble
when I used JobLauncherTestUtils spring doesn't know which job to inject and I don't know how to specify that to test the jobs one by one.
2nd trouble when I separate my configuration to testing only one job, JobLauncherTestUtils couldn't been creating because it's need dataSource, as I used MongoDb with mongotemplate I don't use dataSource.
the stack error look like :
Caused by: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'jobRepositoryTestUtils': Unsatisfied dependency expressed through method 'setDataSource' parameter 0; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'javax.sql.DataSource' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}
Hope anybody will help me to find a solution. Thanks in advance.
1st trouble when i used JobLauncherTestUtils spring don't know wich job to inject and i don't know how to specify that to test the jobs one by one.
You can specify which job to launch using JobLauncherTestUtils#setJob. Please see JobLauncherTestUtils throws NoUniqueBeanDefinitionException while trying to test spring batch steps
2nd trouble when I separate my configuration to testing only one job, JobLauncherTestUtils couldn't been creating because it's need dataSource, as I used MongoDb with mongotemplate I don't use dataSource.
According to the error Error creating bean with name 'jobRepositoryTestUtils', it is not JobLauncherTestUtils that could not be created but jobRepositoryTestUtils. The repository test utils is a convenience class to create and remove job executions from a database (See its javadoc). So it requires a datasource. If you don't have a data source in your test context, you need to remove this bean declaration.
We're creating large-scale projects.
spring-boot project which uses curator to interact with zk servers, how many CuratorFramework instance should we create?
What level of work can a CuratorFramework instance deal with?
As noted on Curator's website - http://curator.apache.org/curator-framework/index.html - "CuratorFramework instances are fully thread-safe. You should share one CuratorFramework per ZooKeeper cluster in your application."
Newbie alert.
I'm trying to write a simple module in Vertx that polls the database (PostGres) every 10 seconds and pushes the results to the clients. I'm thinking of confining the blocking code (queries the database via JDBC) in a worker verticle and rest of the above layers are completely non-blocking and async.
This module will be packaged as a jar and distributed to a different apps (typically webapps) which can subscribe to the event bus via the javascript bridge.
My question here is in a clustered environment where I have 5 processes of the webapp running with the vertx modules, how can I ensure that there's only one vertx verticle querying the database. I don't want all the verticles querying the database and add more load. Or is there a different way to think to solve this problem. I'm using Vertx version 3.4.1
So there are 2 ways how your verticle can be multiplied:
If you instantiate multiple instances when you deploy your verticle
If you start to cluster your vert.x instances in different jvm's or different hosts
You could try to control the number of instances of your verticle which executes the query. Means you ensure, that the verticle only exists in one of your vert.x instances and your verticle is deployed with only one instance.
But this has several drawbacks:
your deployment is not transparent, means your cluster nodes differ in the deployment structure.
if your cluster node dies, where the query verticle is running, then you have no fallback.
So the best thing is, to deploy the verticle on all instances and synchronize it.
I see 3 possibilites:
Use hazelcast (the clustermanager of vert.x) to synchronize
http://vertx.io/docs/apidocs/io/vertx/spi/cluster/hazelcast/HazelcastClusterManager.html#getLockWithTimeout-java.lang.String-long-io.vertx.core.Handler-
There are also datastructures available, which are synchronized over
the cluster
http://vertx.io/docs/apidocs/io/vertx/spi/cluster/hazelcast/HazelcastClusterManager.html#getSyncMap-java.lang.String-
Use your database as synchronization point. you could add a simple
table which stores the last execution time in millis. The polling
modules, will first check if it is time to execute the next poll. If
the polling module executes the poll it also updates the time. This
has to be done in one transaction with a explicit lock on the time
table.
You use redis with the https://redis.io/commands/getset
functionality. You can store the time in millis in a key and ensure
with the getset method, that the upgrade of the time is atomic. So only the polling module which could set the key in redis, will execute the poll.
I'm giving out my naive solution here, I don't know if it would completely solve your problem or not but here is my thought process.
1) Polling bit, yes indeed you can have a worker verticle for blocking call's [ or else you could use Async bit here too IMHO because you already have Async Postgress JDBC client ] for the every 10secs part. code snippet like this can help you
vertx.setPeriodic(10000, id -> {
// This handler will get called every 10 seconds
JsonObject jdbcObject = fetchFromJdbc();
eventBus.publish("INTRESTED_PARTIES", jdbcObject);
});
2) For the listening part all the other verticles can subscribe to event bus and listen for the that address and would be getting the message whenever things would happen
3) This is for ensuring part that not all running instances of your jar start polling the database, for this I think the best possible way to handle would be not deploying the verticle in any jar and running the verticle in an standalone way using runtime vertx command like
vertx run DatabasePoller.java -cluster
And if you really want to be very fancy you could throw in Service Discovery for ensuring part that if the service of the verticle is already register then no other deployments would trigger registrations.
But I want to give you thumbs up on considering the events for getting that information much better way for handling inter-system communication.
I was reviewing the new features in Dalston. I was curious how to appropriately use the ServiceRegistry for Consul.
In both the register and deregister methods, it uses a ConsulRegistration object. Where do I get this object to us in the deregister?
I checked DiscoveryClient and it seems to return ServiceInstance.
The scenario I am thinking of is to remove zombie services and I was to deregister an instance that I believe is bad.
You can autowire ConsulRegistration object with Spring Boot.
The below test class might be helpful for you.
Spring Cloud Consul: ConsulServiceRegistryTests
I have two database configuration javaconfig classes - one for JPA purposes with transactionManager() and entityManagerFactory() #Bean methods and one config class for non-JPA JDBCTemplate based query submission to access data from that database. The overall idea is to read using JDBCTemplate to read data and persist the data, after transformation, into the JPA based datasource. I am using Spring Boot to enable auto configuration. My test fails with:
java.lang.IllegalArgumentException: Not an managed type:
I have both spring-boot-starter-jdbc and spring-boot-starter-data-jpa in my build.gradle. My gut feeling is that the two data sources are in collision course with each other. How do I enforce the use of each of these datasources for the two use-cases that I mentioned earlier - one for JPA and another for JDBCTemplate purposes?
Details (Added after Dave's reply):
My service classes have been annotated with #Service and my repository classes have #Repository. Service uses repository objects using #Autowired though there are some services that are JDBCTemplate-based for data retrieval.
More complex depiction of my environment goes as follows (logically): JDBCTemplate(DataSource(Database(DB2)))--> Spring Batch Item Reader;Processors; Writer --> Service(Repository(JPADataSource(Database(H2)))). Spring batch item processors connect to both databases using services. For spring batch, I am using a H2 Job repo database (remote) to hold job execution details. Does this make sense? For Spring batch, I am using de.codecentric:spring-boot-starter-batch-web:1.0.0.RELEASE. After getting past the entityManagerFactory bean not found errors, I want to have control over the wiring of the above components.
I don't think it's anything to do with the data sources. The log says you have a JPA repository for a type that is not an #Entity. Repositories are automatically scanned from the package you define #EnableAutoConfiguration by default. So one way to control it is to move the class that has that annotation to a different package. In Boot 1.1 you can also set "spring.data.jpa.repositories.enabled=false" to switch off the scan if you don't want it. Or you can use #EnableJpaRepositories as normal.