I want to use tibco in my jms application. Can any one help me how can I use tibco and also please what are the benefits from tibco.
Take a look at the samples directory in your Tibco EMS installation directory. It provides samples for the most common scenarios using the ems libs directly.
If you are using Spring to wire up your messaging there really isn't anything different you do for EMS compared to connnecting to ActiveMQ for example. Create a MessageListenerContainer or a JMSTemplate and you are on your way.
The different between TIBCO EMS and other JMS providers is a BIG question (bascially a trade-off between price, your open-source affinity, 24/7 customer support etc.)
How to use it ?
I would recommend writing your own example JMS consumer, straigth from examples from a good book, for example: Java Message Service, by Richard Monson-Haefel and others.
(this one is small but concise)
and then configure your example with arguments like this:
For TIBCO's EMS JNDI:
-jndiContextFactory com.tibco.tibjms.naming.TibjmsInitialContextFactory
-jndiProviderUrl tibjmsnaming://localhost:7222
-topic TEST
..
Related
I'm using apache camel for consuming an IBM Mq, I use jms for that, everything is ok that works fine, but in the performance testing the api create a lot of dynamic queues but just use once, I've used a lot of properties for solve this problem but I didn't get it yet. my api use a pattern InOut so the responses are in queue in a dynamic queue, when exist a lot of them, for example my api create 50 dynamic queues, but just use 3 of them.
Here are the properties I used to solve it, but didn´t work for me:
-maxConcurrentConsumers
-conccurrentConsumers
-threads
I found a solution for this and is this.
this is my consume to mq
.setHeader("CamelJmsDestinationName",
constant("queue:///"+queue+"?targetClient=1"))
.to("jms://queue:" + queue
+"?exchangePattern=InOut"
+"&replyToType=Temporary"
+"&requestTimeout=10s"
+"&useMessageIDAsCorrelationID=true"
+"&replyToConcurrentConsumers=40"
+"&replyToMaxConcurrentConsumers=90"
+"&cacheLevelName=CACHE_CONSUMER")
.id("idJms")
and this is the properties to connect the mq
ibm.mq.queueManager=${MQ_QUEUE_MANAGER}
ibm.mq.channel=${MQ_CHANNEL}
ibm.mq.connName=${MQ_HOST_NAME}
ibm.mq.user=${MQ_USER_NAME}
ibm.mq.additionalProperties.WMQ_SHARE_CONV_ALLOWED_YES=${MQ_SHARECNV}
ibm.mq.defaultReconnect=${MQ_RECONNECT}
# Config SSL
ibm.mq.ssl-f-i-p-s-required=false
ibm.mq.user-authentication-m-q-c-s-p=${MQ_AUTHENTICATION_MQCSP:false}
ibm.mq.tempModel=MQMODEL
the issue was in the MQ Model, the MQModel has to be shared if you are using the pattern inOut, this is because the concurrent create dynamic queues using the mqModel
I would like to create a JMS connection from a Java SE application in a broker-agnostic way.
I'm comparing to JDBC with its URL scheme for database connections. This creates independence from the actual implementation.
For JMS I haven't found something similar. I'm aware that in Java EE the JNDI will fulfill this role, but this is Java SE.
I don't want to tie my code to any particular queue broker as my needs are pretty simple JMS 1.1 send/receive of text messages.
I've looked at Spring Boot too because it is usually good at providing some level of agnosticism. But even with Spring Boot, I do not see such possibility.
JNDI is the way you write your JMS application to connect in a broker-agnostic way. JNDI client classes are part of Java SE. Both Spring and non-Spring Java SE applications use JNDI for this kind of integration.
Any JMS implementation should also provide a JNDI implementation that can be plugged into your application. Typically this is done by placing a file named jndi.properties on your classpath and putting the proper configuration for whatever JNDI implementation you're using into that file. When you create an empty InitialContext the jndi.properties file on your classpath is read automatically. The key=value pairs in jndi.properties are put into the InitialContext so that when you perform a lookup everything works with the implementation you've chosen. You can also configure this programmatically if you like by supplying the implementation specific details to the InitialContext via a constructor.
By using both the JMS and JNDI APIs in your Java SE application and externalizing broker-specific connection details to your jndi.properties file you can effectively isolate your applications from broker-specific code so you can deploy your app and work with different brokers with a few simple changes in a properties file.
The JNDI client implementation will come from whoever is providing the JMS implementation. The JNDI client essentially comes in the form of an javax.naming.spi.InitialContextFactory implementation packaged in a jar and there is usually documentation describing the available properties.
Here are a few examples:
The ActiveMQ 5.x broker provides org.apache.activemq.jndi.ActiveMQInitialContextFactory available in their activemq-client-<version>.jar. Documentation is available here.
The ActiveMQ Artemis broker provides org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory available in their artemis-jms-client-<version>.jar. Documentation is available here.
To be clear, the JMS specification doesn't require the use of JNDI to look-up admin objects, but it establishes the convention and expectation that JMS providers will do so. Section 4.2 of the JMS 1.1 specification states:
Although the interfaces for administered objects do not explicitly depend on JNDI, JMS establishes the convention that JMS clients find them by looking them up in a namespace using JNDI.
and later it says:
It is expected that JMS providers will provide the tools an administrator needs to create and configure administered objects in a JNDI namespace. JMS
provider implementations of administered objects should be both javax.naming.Referenceable and java.io.Serializable so that they can be stored in all JNDI naming contexts.
In my experience, JMS providers are usually eager to provide a JNDI implementation because they won't be as competitive without it since any alternative solution will not be standards compliant and will force users to implement non-portable code.
If you run into a provider that doesn't provide a JNDI implementation you could implement your own following the same pattern used by ActiveMQ 5.x, ActiveMQ Artemis, and Qpid JMS. These 3 implementations are client-side only and simply instantiate the admin objects based on the configuration provided to the InitialContext. Most of the code is boiler plate, and what isn't is very straight-forward.
I would like to migrate a multi-threaded application in JSE to Spring Integration but I have to clarify some points before. First of all, the application will have the following Spring integration components:
JMS to Transformer to router to TCPOut
TcpIn (to router) to Transformer to JMS
In this context, I have to load all the TCP connections dynamically from a configuration file. I saw a couple of example of this here in StackOverflow (based in the FTP sample). These samples could be enough for the first part but I am looking for how to do that in Spring Boot and what is the best (and elegant) way to create this type of configuration.
Finally, I have to access to each different context (this is maybe the most important) from a type of Swing monitor to start/stop manually this TCP connections. Is this possible? What do you suggest me to do?
All my current components are java based configuration (not DSL).
See my answers to this question and its follow-up for examples of how to dynamically create application contexts using Java Configuration.
Also, take a look at the new feature in the Java DSL for dynamically registering/removing integration flows with the context. The 1.2 version of the DSL, containing this feature, will be released shortly.
You can stop/start endpoints using JMX or a control bus, or programmatically.
I'm new to JMS programming (Java).
I have a machine M1, in a domain D1 and a machine M2 in another domain D2.
I have in M1 a JMS producer. And in M2 a JMS consumer. Both have as servers JBoss 7.2.
So it seems the only solution is to create a JMS bridge.
I'm reading the official documentation. So I wonder if creating an SSH tunnel is necessary.
Second, in which hornetq-configuration.xml file should I set the following configuration?
<bridge name="my-bridge">
<queue-name>jms.queue.sausage-factory</queue-name>
<forwarding-address>jms.queue.mincing-machine</forwarding-address>
<filter-string="name='aardvark'"/>
<transformer-class-name>
org.hornetq.jms.example.HatColourChangeTransformer
</transformer-class-name>
<retry-interval>1000</retry-interval>
<ha>true</ha>
<retry-interval-multiplier>1.0</retry-interval-multiplier>
<reconnect-attempts>-1</reconnect-attempts>
<failover-on-server-shutdown>false</failover-on-server-shutdown>
<use-duplicate-detection>true</use-duplicate-detection>
<confirmation-window-size>10000000</confirmation-window-size>
<user>foouser</user>
<password>foopassword</password>
<static-connectors>
<connector-ref>remote-connector</connector-ref>
</static-connectors>
<!-- alternative to static-connectors
<discovery-group-ref discovery-group-name="bridge-discovery-group"/>
-->
</bridge>
Should it be in the in JBoss server of the JMS producer machine or consumer machine?
My third question is, is there a difference in settings between JMS bridge and core bridge?
I would be so thankful for any additional information and explainations!
Thank you a lot!
I know this is little late for OP, may be this information helps someone.
Firstly, the difference between Core and JMS bridge.
Read doc here
Core bridges are for linking a HornetQ node with another HornetQ node and do not use the JMS API. A JMS Bridge is used for linking any two JMS 1.1 compliant JMS providers.
The Core bridge uses proprietary HornetQ core api so it can only connect two HornetQ servers. Whereas JMS bridges use the JMS API so could connect any JMS1.1 API complaint servers.eg: HornetQ to ActiveMQ.
The configuration mentioned in question is Core bridge and can be configured in the source server.Since you seem to connect two HornetQ server Core bridges is the way forward. That said, in your case you could use JMS bridges as well since both are JMS complaint.But the recommended approach would be to use Core bridge due to performance advantage gain.
Finally, the JBoss installation server comes with some handy examples.You could find Core bridge example under [JBOSS_HOME]\jboss-as\extras\hornetq\examples\jms\bridge.
It's simple: I have an MDB and an EJB that sends messages to a topic (or queue). JBoss complains that the topic is not bound to the JNDI context.
I want to have the topic/queue to be automatically created at best, or at least to have a standard way to define it, per application (say, in ejb-jar/META-INF)
this question and this blogpost show us how to do it in an application server specific way. This surely works, but:
I want to use the #MessageDriven annotation
I want the setting not to be global for the application server
I want the setting to be portable
It seems impossible to do this, with JavaEE 5 at least.