Showing posts with label Servicemix. Show all posts
Showing posts with label Servicemix. Show all posts

Monday, April 16, 2012

Quick Note on How to remove/change /cxf from context path of CXF OSGi service.

By Default, when a CXF servlet endpoint is deployed in Servicemix OSGi container the context path for the endpoint address contains "/cxf".
This causes resulting endpoint URL being something like http://localhost:9090/cxf/myservice . This is not always a desirable URL and many times needed to change to more generic (technology neutral) URL for publishing the endpoint.

This default context can be changed in one of the two ways as follows:

1. It can be changed by adding org.apache.cxf.servlet.context=/myservice to etc/org.apache.cxf.osgi.cfg.

2. By running following commands to alter configuration in container using configuration management service in Servicemix container.
       config:edit org.apache.cxf.osgi
       config:propset org.apache.cxf.servlet.context /myservice
       config:update

Tuesday, November 8, 2011

Short Note on How to install Servicemix 4 as windows service.

To install Servicemix 4 as windows service need to start SMX from console and run features:install wrapper and wrapper:install and follow the instructions that are displayed by second karaf command.

Here is the output from a sample run :


karaf@root> features:install wrapper
karaf@root> wrapper:install
Creating file: C:\work\apache-servicemix-4.4.1-fuse-01-06\bin\karaf-wrapper.exe
Creating file: C:\work\apache-servicemix-4.4.1-fuse-01-06\etc\karaf-wrapper.conf

Creating file: C:\work\apache-servicemix-4.4.1-fuse-01-06\bin\karaf-service.bat
Creating file: C:\work\apache-servicemix-4.4.1-fuse-01-06\lib\wrapper.dll
Creating file: C:\work\apache-servicemix-4.4.1-fuse-01-06\lib\karaf-wrapper.jar
Creating file: C:\work\apache-servicemix-4.4.1-fuse-01-06\lib\karaf-wrapper-main
.jar

Setup complete. You may want to tweak the JVM properties in the wrapper configu
ration file:
C:\work\apache-servicemix-4.4.1-fuse-01-06\etc\karaf-wrapper.conf
before installing and starting the service.


To install the service, run:
C:> C:\work\apache-servicemix-4.4.1-fuse-01-06\bin\karaf-service.bat install

Once installed, to start the service run:
C:> net start "karaf"

Once running, to stop the service run:
C:> net stop "karaf"

Once stopped, to remove the installed the service run:
C:> C:\work\apache-servicemix-4.4.1-fuse-01-06\bin\karaf-service.bat remove


Hope this helps and serves as note to myself for future.

Wednesday, February 2, 2011

Enabling JMX monitoring in Servicemix for pax-web jetty instance.

In Servicemix 4.x OSGi HTTP service is provided using pax-web. By default, it doesn't expose MBean for underlying Jetty instance running inside pax-web.

To enable monitoring this jetty instance you need to use fragment bundle that would connect underlying jetty to Servicemix MBeanServer using additional jetty configuration.

Here are steps to do this:

1. Create a OSGi Fragment-Bundle which will attach to pax-web-jetty OSGi service. Bundle Fragment project pom.xml contains following:

<project xmlns="http://maven.apache.org/POM/4.0.0"
xsi="http://www.w3.org/2001/XMLSchema-instance"
schemalocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelversion>4.0.0</modelversion>
<groupid>org.ops4j.pax.web</groupid>
<artifactid>config-jetty-jmx</artifactid>
<version>1.0.0-SNAPSHOT</version>
<packaging>bundle</packaging>
<name>OPS4J Pax Web - Configuring Jetty JMX connection</name>
<properties>
<bundle.symbolicname>org.ops4j.pax.web.config-jetty-jmx</bundle.symbolicname>
</properties>
<build>
<plugins>
<plugin>
<groupid>org.apache.felix</groupid>
<artifactid>maven-bundle-plugin</artifactid>
<version>2.2.0</version>
<extensions>true</extensions>
<executions>
<execution>
<id>bundle-manifest</id>
<phase>process-classes</phase>
<goals>
<goal>manifest</goal>
</goals>
</execution>
</executions>
<configuration>
<instructions>
<bundle-symbolicname>${bundle.symbolicName}</bundle-symbolicname>
<bundle-version>${pom.version}</bundle-version>
<fragment-host>org.ops4j.pax.web.pax-web-jetty</fragment-host>
</instructions>
</configuration>
</plugin>
</plugins>
</build>
</project>


2. This bundle (Fragment) would have additional Jetty configuration xml file jetty.xml which would (reside in src/main/resources folder) look like this:

<configure class="org.mortbay.jetty.Server">
<call id="jettyMBeanServer" class="java.lang.management.ManagementFactory" name="getPlatformMBeanServer">

<!-- =========================================================== -->
<!-- Initialize the Jetty MBean container -->
<!-- =========================================================== -->
<get id="Container" name="container">
<call name="addEventListener">
<arg>
<new class="org.mortbay.management.MBeanContainer">
<arg><ref id="jettyMBeanServer"></ref>
<call name="start">
</call>
</arg>
</new>
</arg>

</call>


3. Once the fragment bundle is built install it in Servicemix instance which is not currently running pax-web OSGi services. (I used Servicemix instance with minimal bundles only config feature was installed) I installed it using osgi:install file:///.... or something like osgi:install mvn:org.ops4j.pax.web/config-jetty-jmx where the groupId for my Fragment bundle project was org.ops4j.pax.web and artifactId config-jetty-jmx.

4. Once this is installed you can install pax-web. I deployed war feature which installs and starts pax-web feature.

5. At this stage your Fragment bundle would get attached to pax-web-jetty Host Bundle and enable JMX monitoring. To confirm this if you run osgi:list you should see something like (Note Fragment and Host entries):

[33] [Resolved ] [ ] [ 60] OPS4J Pax Web - Configuring Jetty JMX connection (1.0.0.SNAPSHOT)
Hosts: 39
[ 34] [Active ] [ ] [ 60] geronimo-servlet_2.5_spec (1.1.2)
[ 35] [Active ] [ ] [ 60] Apache ServiceMix :: Bundles :: jetty (6.1.26.1-fuse)
[ 36] [Active ] [ ] [ 60] OPS4J Pax Web - API (0.7.3)
[ 37] [Active ] [ ] [ 60] OPS4J Pax Web - Service SPI (0.7.3)
[ 38] [Active ] [ ] [ 60] OPS4J Pax Web - Runtime (0.7.3)
[ 39] [Active ] [ ] [ 60] OPS4J Pax Web - Jetty (0.7.3)
Fragments: 33
[ 40] [Active ] [ ] [ 60] OPS4J Pax Web - Jsp Support (0.7.3)
[ 41] [Active ] [ ] [ 60] OPS4J Pax Web - Extender - WAR (0.7.3)
[ 42] [Active ] [ ] [ 60] OPS4J Pax Web - Extender - Whiteboard (0.7.3)
[ 43] [Active ] [ ] [ 60] OPS4J Pax Url - war:, war-i: (1.1.3)
[ 44] [Active ] [Created ] [ 60] Apache Karaf :: WAR Deployer (2.0.0.fuse-02-00)

6. At this stage if you start JConsole and look connect to running Servicemix instance you should be able to see following MBeans appearing in MBeans tab:
a. org.mortbay.jetty.servlet
b. org.mortbay.thread
c. org.ops4j.pax.web.service.jetty.internal

I did see some InstanceAlreadyExists exceptions in Servicemix instance but wasn't able to resolve them quickly so just left there since in my opinion they are harmless.

I hope this helps anyone who wants to configure internal Jetty instance run by pax-web in Servicemix/Karaf.

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.

Thursday, August 21, 2008

Spring jmsTemplate threading issue

I recently encounter a problem while working on some Servicemix bug and it turned out that Servicemix jms provider is using spring-jms jmsTemplate and when there are multiple threads trying to do send receive (receiveSelected() to be precise) some of the messages are dropped.

While doing further investigation I found that multiple threads are using the same instance of spring-jms jmsTemplate that is created by the jms provider and this was causing some threading issue so thing to remember is to make the calls to jmsTemplate.receiveSelected() (atleast this one) synchronized.

UPDATE: I was too quick to diagnose the problem as jmsTemplate issue. With more drill down I was able to reproduce the problem with pure jmsTemplate and ActiveMQ combination and looks like a ActiveMQ issue than spring-jms. My friend Gary is getting it fixed in ActiveMQ currently.

Monday, August 11, 2008

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)