I am using Spring Boot with spring-rabbitmq. My connection factory is configured in application.properties and it seems to be nice.
My aim is: during start check if exists queue if specific name, and in case of absence create such queue. I am not sure how to deal with it. What beans should I create in config class? From what I read it should be RabbitAdmin, however I am not sure about it. Can you help me?
Everything is described clearly in the Reference Manual:
The AMQP specification describes how the protocol can be used to configure Queues, Exchanges and Bindings on the broker. These operations which are portable from the 0.8 specification and higher are present in the AmqpAdmin interface in the org.springframework.amqp.core package.
And further:
When the CachingConnectionFactory cache mode is CHANNEL (the default), the RabbitAdmin implementation does automatic lazy declaration of Queues, Exchanges and Bindings declared in the same ApplicationContext.
So, you should declare Queue, Exchange and Binding beans in your application context and AmqpAdmin will take care about their definition on the target Broker.
There must be a note that according AMQP protocol, if entity already exists on the Broker, the declaration is just silent and idempotent.
So, in your case you don't need to worry about queues existence and just provide their declarations as beans in the application context.
Related
I have a ReactiveDiscoveryClient that provides a method Flux<ServiceInstance> getInstances(String serviceId). I want to use the result of that method in my GatewayFilterFactory's apply method. However,
ServiceInstance si = reactiveDiscoveryClient.getInstances(config.getServiceId()).block();
fails because the block operations are not allowed. Is there anyway around it?
What I've done is cheat since my ReactiveDiscoveryClient has an in-memory map that contains the services and I just provide an extra method that gets the value I need.
That's rare, as by default, those actions are allowed. From the Spring Cloud Documentation:
27.1. #EnableDiscoveryClient
Spring Cloud Commons provides the #EnableDiscoveryClient annotation. This looks for
implementations of the DiscoveryClient and ReactiveDiscoveryClient
interfaces with META-INF/spring.factories. Implementations of the
discovery client add a configuration class to spring.factories under
the org.springframework.cloud.client.discovery.EnableDiscoveryClient
key. Examples of DiscoveryClient implementations include Spring Cloud
Netflix Eureka, Spring Cloud Consul Discovery, and Spring Cloud
Zookeeper Discovery.
Spring Cloud will provide both the blocking and reactive service
discovery clients by default. You can disable the blocking and/or
reactive clients easily by setting
spring.cloud.discovery.blocking.enabled=false or
spring.cloud.discovery.reactive.enabled=false. To completely disable
service discovery you just need to set
spring.cloud.discovery.enabled=false.
At least for what it's told in the last paragraph, you should be able to perform a block(). Anyway, you could try by setting these params, as should be enough to be allowed to invoke it:
spring.cloud.discovery.blocking.enabled=true
spring.cloud.discovery.reactive.enabled=true
spring.cloud.discovery.enabled=true
Also, not sure if related, but note this warning as well (just in case)
The use case is following.
I am passing producer or consumer reference over many objects instances in Java code.
At some of them I would like to do some checks for the Kafka configuration.
It means I would like to get back, what effective configuration is stored in Kafka Producer/Consumer (including defaults).
I do not see anthing explicit in java docs:
KafkaProducer
KafkaConsumer
So, how to get back Kafka producer and consumer configuration?
Unfortunately it's not possible. I have to admit it could be a useful feature for showing the "core" configuration properties at least (avoiding the possibility to get the "secrets" for authentication stuff for example).
The only solution that I see today for you is to have a link between the consumer/producer instance and the related properties bag used for setting the client configuration. I understand it's a waste of memory because such configuration is internally in the client but you need to keep your properties bag for having it.
I am currently successfully using an MQConnectionFactory to connect and post to a Websphere MQ queue using JMS.
However I'm getting a requirement from a client that I must use mqclient.ini instead.
So my question is, for a 'standard' JMS setup, should I be using:
Straight up MQConnectionFactory instance
A JMS configuration file
An mqclient.ini file
? What would one use one over the other? Does one take precedence over another?
The mqclient.ini and JMSconfig files are used setting attributes like what client side exits to use, TCP level overrides etc. They are basically used for configuring the client libraries/jars. They are not meant for application configuration for example what queue manager or queue to use. This sort of info, connection factory or destination info, is typically pulled from a JNDI so that the configuration can be modified without affecting application.
Maybe it is a extreme newbie question, but:
I'm about to implement sending a message to a queue. The problem is, all I know is that it is a JMS Queue, but no idea, which implementation (it is just called ESB).
So now I have to have a connectionFactory bean, and all examples I saw use ActiveMqConnectionFactory. Is there any generic factory/implementation? JMS is a standard, so I should not be bound to some specific factory implementation, right?
Correct. What you need is javax.jms.ConnectionFactory and javax.jms.Destination.
However, as you say it is ESB, there should some connection properties to the server, e.g. JNDI, or some service-locator to connect to the bus and call appropriate service.
Actually not enough info, what you have in hands regarding that ESB
I have an enterprise application running on JBoss which contains a number of message driven beans. At the moment, each MDB listens for messages from a destination which is defined via annotations on the MDB class.
Is it possible to set the detination that MDBs subcribe to at runtime, rather than configuring this via annotations of a deployment descriptor?
Many thanks.
Generally you can't reconfigure existing MDB to listen another queue, but you can try this method to specify system properties instead of real queue names. System properties can be changed in runtime through JMX