I try to configure a JMS queue with delay multiplier in WildFly 8.2.0, but I have an issue during stadalone.xml parsing when the server is started. Obviously, the parameter <redelivery-delay-multiplier> is not recognised.
But when I see the release note of WildFly 8.2.0, it's shipped with HornetQ 2.4.5 which includes this parameter.
Any one please has an idea about this configuration and how to make the delay multiplier work on WildFly 8?
Thank you
Related
A Issue raised to change HTTP version 1.1 only in web server configuration.
I am using wildfly 10 as my server.
I have tried using connector varible but it is not allowed in wildfly 10 so help me out with this.
In undertow subsystem configuration you should add require-host-http11="true" to your http/http-listener.
for more configuration options see https://wildscribe.github.io/WildFly/13.0/subsystem/undertow/server/http-listener/index.html#attr-require-host-http11
im trying to migrate JBoss AS7.1 to Wildfly 10, i just followed some threads and i came upon this AS7 to Wildfly 10 guide. Basically it just tells how to migrate server configuration as well as application configuration.
But the problem is, it says to execute ":migrate" function "/subsystem=jacorb:migrate" on jboss cli (Jboss AS7.1 because it says execute on legacy subsystem) but it always throws an error, see below
No handler for migrate at address
Anyone familiar in executing migrate on jboss cli please point me to the right direction
UPDATES
I opted to migrate to wildfly10 from jboss-as7.1 manually (labor intensive, hassle), maybe if i have time to investigate about this i could feedback it there but as of know i time is of the essence and i need to migrate immediately.
I'm totally a newbie in Java Enterprise and I have a lot stuff yet to learn. Right now I'm working which involves JMS using JBoss and ActiveMQ. An application sends messages to queues in JBoss and my goal is to access those messages using any message broker (in this case I tried to use ActiveMQ). So I think it's better for me to embed ActiveMQ to JBoss. I used the link below as the guidance :
http://activemq.apache.org/integrating-apache-activemq-with-jboss.html
I followed every single steps in the guide except that I used JBoss 4.2.3 and ActiveMQ 5.1.1. If this problem results from the different version of the tools, I think I can't help it out because other versions seem does not work on my machine. When I run JBoss to test whether the embedding is working or not, I can't see anything running on port localhost:61616 which is the default port for ActiveMQ, although JBoss seems run well. My question is :
Is any one know how to fix this? Or has anyone ever experienced such problem?
Is there any way to access queue in Jboss?
If this question is pretty ambiguous or need more details, let me know. Thanks in advance for any help.
I'm quite sure the embedded broker is started (transport vm://localhost) which results in a working JMS broker for that VM. But this broker isn't reachable from outside (via tcp or anything else)
Do you see any error in the log when launching jboss? I managed to make it work with Jboss 4.2 and ActiveMQ 5.4, and once integrated it only gives you a small hint that is working correctly with some info message saying "broker started in port ..." .
Also you can try to use the sample producers and receivers in ActiveMQ to test if the queue is working correctly.
If you still have problems I can try to help
We are running portlets in WebSphere 6.01, using Java 1.4. We want to send JMS messages to a JBoss 5 queue, running Java 5 (or maybe 6, but it's certainly newer than 1.4). Trying to connect using JNDI is not working, since we have to include the JBoss client jars in the classpath of the portlet, and they are Java 1.5. So I get an unsupported major/minor error when I try to create the InitialContext.
Can we connect straight to JBoss without using JNDI? Or is there some way to get around this issue I can't think of?
Even if you were able to connect to JMS without going through JBoss's JNDI, you would still need to include the JBoss client JAR in order to use JMS. Both JNDI and JMS are APIs, and you need the server's implementation of that client API in order to talk to the server.
If it's just your JNDI classes that prereq Java 5 and not the JBoss classes then you can do this. But you would have to set all of the properties of the objects and that is provider-specific. The WebSphere MQ JMS samples show how to do this with WMQ and you would need to know the property and value names for JBoss to make the equivalent code. Here is a code snippet from the WMQ JmsProducer.java sample:
JmsFactoryFactory ff = JmsFactoryFactory.getInstance(WMQConstants.WMQ_PROVIDER);
JmsConnectionFactory cf = ff.createConnectionFactory();
// Set the properties
cf.setStringProperty(WMQConstants.WMQ_HOST_NAME, host);
cf.setIntProperty(WMQConstants.WMQ_PORT, port);
cf.setStringProperty(WMQConstants.WMQ_CHANNEL, channel);
cf.setIntProperty(WMQConstants.WMQ_CONNECTION_MODE, WMQConstants.WMQ_CM_CLIENT);
cf.setStringProperty(WMQConstants.WMQ_QUEUE_MANAGER, queueManagerName);
// Create JMS objects
connection = cf.createConnection();
session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
if (isTopic) {
destination = session.createTopic(destinationName);
}
else {
destination = session.createQueue(destinationName);
}
producer = session.createProducer(destination);
On the other hand, if your JBoss classes prereq Java 1.5 then you need to run Java 1.5 or better.
Depending on the JBoss version you can directly instantiate all the JMS objects.
One particular version:
see http://www.jboss.org/file-access/default/members/jbossmessaging/freezone/docs/usermanual-2.0.0.beta1/html/using-jms.html
(Section 5.5. Directly instantiating JMS Resources without using JNDI)
I think JNDI is the only way that you can create JMS connection factories and destinations (queue or topic), and these are your means of communication.
In fact using JNDI is a way to be independant of the JMS provider, because you can easly change it.
But if you've got no problem with that most provider offer facilities to create a connection factory and destinations
It sounds like the problem isn't with JNDI but with the conflicting classnames between the environments.
You could try doing the classloading yourself when you try to instantiate the JBOSS client classes. That way you get a separate classloader from the one that loaded the Portlet. Just make sure you understand whether you need Parent-first or Parent-last behavior. Also on that page is debugging classloading which can show you how to set the Classpath for the classloader so you can isolate the JBOSS libraries and avoid classname collisions. It is a good resource for understanding even advanced classloading issues.
I've been going through several examples on how to add MBeans to JBoss 5.0 so they can be configured though the JMX Console, but none of these examples have ever shown up in the JMX view. I've now tried to get ehCache's JMX integration to work to no avail.
I'm trying (as in the ehCache documentation) the following:
CacheManager manager = CacheManager.create("./ehcache.xml");
MBeanServer mBeanServer = ManagementFactory.getPlatformMBeanServer();
ManagementService.registerMBeans(manager, mBeanServer, false, false, false, true);
I never see any errors with my own or now with the ehCache version, but it never shows up in the JMX view. I'm wondering - is there a setting I need to make to to the JBoss configuration to get it to pick up these additions? Am I missing something fundamental? Any hints?
Thanks for any help. I'm pulling my hair out here.
If you're running JBoss on Java 5 or above, then you'll likely have 2 MBean servers running: the "platform" mbean server, which is hosted by the JVM, and the JBoss MBean server, which is hosted by the JBoss code. The two have nothing to do with each other.
Your posted code will register ehcache's mbean in the JVM platform server, which is no use to you.
The easiest way to get a programmatic reference to the JBoss MBean server is
org.jboss.mx.util.MBeanServerLocator.locateJBoss()
Try using that instead of
ManagementFactory.getPlatformMBeanServer();