Showing posts with label Apache. Show all posts
Showing posts with label Apache. Show all posts

Friday, April 10, 2009

Quick and short post on jmxrmi exception in FUSE HQ.

If you even see following exception when using FUSE HQ or Hyperic HQ it is most likely an issue with what JDK/JRE you (or rather HQ) is using. The problem occurred while collecting statistics from FUSE ESB (Servicemix) and FUSE Message Broker (ActiveMQ).

Here is the exception:

org.hyperic.hq.product.PluginException: javax.naming.NameNotFoundException: jmxrmi
at org.hyperic.hq.product.jmx.MxServerDetector.discoverServices(MxServerDetector.java:404)
at org.hyperic.hq.product.ServerDetector.discoverResources(ServerDetector.java:203)
at org.hyperic.hq.autoinventory.agent.server.RuntimeAutodiscoverer.doRuntimeScan_internal(RuntimeAutodiscoverer.java:272)
at org.hyperic.hq.autoinventory.agent.server.RuntimeAutodiscoverer.doRuntimeScan(RuntimeAutodiscoverer.java:205)
at org.hyperic.hq.autoinventory.ScanManager.mainRunLoop(ScanManager.java:165)
at org.hyperic.hq.autoinventory.ScanManager.access$000(ScanManager.java:41)
at org.hyperic.hq.autoinventory.ScanManager$1.run(ScanManager.java:107)
Caused by: java.io.IOException: javax.naming.NameNotFoundException: jmxrmi
at mx4j.remote.resolver.rmi.Resolver.lookupStubInJNDI(Resolver.java:100)
at mx4j.remote.resolver.rmi.Resolver.lookupRMIServerStub(Resolver.java:72)
at mx4j.remote.resolver.rmi.Resolver.lookupClient(Resolver.java:52)
at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:119)
at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:38)
at org.hyperic.hq.product.jmx.MxUtil.getMBeanConnector(MxUtil.java:445)
at org.hyperic.hq.product.jmx.MxServerDetector.discoverServices(MxServerDetector.java:401)


The cause in my case:
FUSE HQ agent was using JRE 1.4 bundled with it which was causing the problem.
Why : There are some incompatibilities in JMX stuff when it comes to using the same code with JDK 1.4 and JDK 1.5 and apparently moving to JDK/JRE 1.5 got rid of this problem.
I don't know much about JMX so don't know what all incompatibilities are between tow of them. Anyone who reads (in first place) and knows the differences and could comment on this post it would help everyone.

Tuesday, April 7, 2009

Accessing archetype while using nexus repository manager as proxy

I was trying to use Eclipse with m2eclipse for creating some FUSE ESB project from the archetypes and was getting strange error :

"Unable to create project from archetype [org.apache.servicemix.tooling:servicemix-bean-service-unit:3.3.1.16-fuse -> null]
> The desired archetype does not exist (org.apache.servicemix.tooling:servicemix-bean-service-unit:3.3.1.16-fuse)"


After drilling down more and looking into it I found the problem was :
1. I did configured the nexus index catalog http://repo.open.iona.com/maven2/archetype-catalog.xml correctly.
2. However, I later realized that I am using Nexus repository manager which doesn't automatically download the catalog itself and so it is not getting all the requited information to download the correct artifacts.

The way I fixed this for now is manually downloading the archetype-catalog.xml via my Nexus repository instance like this:

wget http://my-nexus-proxy:8081/nexus/content/repositories/open.iona.m2/archetype-catalog.xml

once the catalog was available locally at my nexus repository I then used the Eclipse m2eclipse plugin in usual manner and it went and download required archetype plugins from the remote repository into my nexus instance.

I really would like to see some option in Nexus which would allow synchronization of such artifacts which are not downloaded normally by maven dependency. Some way of scheduling such stuff (I know we can schedule the task but some smart scheduling for such category of artifacts).

For now manual downloading and sync is the way to get around the problem.

Monday, August 11, 2008

Changes to Apache CXF JMS transport to allow jmsDestination name

Recently Apache CXF JMS transport is modified in order to allow use of jmsDestinationName and jmsReplyDestinationName. Till now CXF JMS only allowed using jndi destination names to lookup queue/destination and was not able to use jms destination names to create queues/topics.

Here is the diff of the schema change to specify the jmsDestinationName and jmsReplyDestinationName.

Example jms:address looks like this:

<jms:address jndiconnectionfactoryname="ConnectionFactory"
jmsdestinationname="dynamicQueues/routertest.SOAPService6Q.text"
jmsreplydestinationname="dynamicQueues/SoapService6.reply.queue">
<jms:jmsnamingproperty name="java.naming.factory.initial"
value="org.apache.activemq.jndi.ActiveMQInitialContextFactory"/>
<jms:jmsnamingproperty name="java.naming.provider.url"
value="tcp://localhost:61500"/>
</jms:address>


This will allow CXF consumer and services to use the real queue names (where JMS provider will allow the creation of the queues) as opposed to use jndi lookup.

handy tip on how to increase jetty HttpClient threadpool size in ServiceMix 3.2.2

I was recently working on some jetty related issue in Servicemix 3.2 and got Servicemix people to update servicemix-http component to have configurable jetty httpClient thread pool size. Before I forget it I wanted to make a note of it so adding this entry.

In Servicemix 3.2.2 and onwards jetty HttpClient threadpool can be configured using following entry in component.properties file.
servicemix-http.jettyClientThreadPoolSize=33

Also, you can configure Servicemix to use Jetty httpClient per httpProvider (by default a single client is shared among all httpProviderEndpoints) by adding

servicemix-http.jettyHttpClientPerProvider=true

Also from ServiceMix 3.2.2 onwards Jetty HttpClient uses nio channel selector implementation of jetty. (previously it was using socket connector which was blocking I/O and was causing thread locking in thread pool in some stress conditions)

Friday, June 6, 2008

Running CXF jms_queue sample in Tomcat

Recently, I wanted run Apache CXF jms_queue sample in tomcat and came across some problems setting up stuff so want to note the things that I had to do for it.

1. need to create the spring.xml and web.xml descriptor for deploying the jms_queue server inside Tomcat.
2. Need to add CXF and ActiveMQ jars to the container classpath. I haven't tried yet to bundle these inside the application war file that is next on my list.
3. Build the sample, create war file and deploy it to tomcat by copying it to webapp directory of the container.
4. start jms broker (I user ant task from the sample that starts embedded broker).
5. Start tomcat container. This will deploy the copied war and start the CXF jms_queue service.
6. run the client from the commandline against the service deployed into Tomcat.

Looks simple isn't it? But I had to spend 1 day figuring out how to make this work.

glitch 1: Service creation wasn't finding WSDL for my service. Reason: WSDL was bundled under WEB-INF/wsdl directory which is not on classpath so I have changed the build.xml to put it under WEB-INF/classes directory.

glitch 2: Wanted to enable logging by adding logging.properties file but wasn't able to find it on classpath. Reason: same as glitch 1 and solved when added it to WEB-INF/classes folder.

I am attaching tar file of my sample directory for future reference here.

EDIT: I couldn't find the way to upload the tar file so I am editing the post to remind me to post the changes in my next post. Not so good but can't help.

EDIT:
Here is how web.xml looks like:


And my spring.xml looks like this:


Finally here is the link to zip file that has the full example.