lundi 12 novembre 2012

How to use perfharness for routes Camel & ActiveMQ


Use Performance Harness for JMS

§   This is the same tool that the WebSphere Message Broker and WebSphere MQ teams use when measuring the products.
§   Available to download on Alphaworks: http://www.alphaworks.ibm.com/tech/perfharness
§   Supports testing JMS, MQ, HTTP, SOAP
§   The tool provides:
Throttled operation (fixed rate or number of messages)
Multiple destinations
Live performance reporting
JNDI
Non JNDI for IBM JMS Providers

Running Perfharness

§   Requires Java 5 minimum
§   Set min and max heap size for the tool: -ms256M -mx256M
§   You have to put all jars of perharness in %ActiveMQ_HOME%\examples\perfharness

Example Output:

Sender1: START
rateR=3137.33,threads=1
rateR=4488.75,threads=1
rateR=4621.33,threads=1
rateR=4680.78,threads=1
rateR=4683.67,threads=1
rateR=4693.88,threads=1
rateR=4683.56,threads=1
Sender1: STOP
totalIterations=128133,avgDuration=26.53,maxrateR=4683.56
ControlThread1: STOP

The first case: Find the max rate for sending messages in a named queue and receiving messages from a named queue.

Sender.bat:

Module to measure “-tc jms.r11.Sender” sends messages to a named queue destination “-d dynamicQueues/testqueue”.
The message referenced in this batch file “Sender.bat” is persistent “-pp”, and transacted “-tx”.

java -cp "..\..\activemq-all-5.3.0-fuse-01-00.jar;./perfharness.jar" JMSPerfHarness -pc JNDI -ii org.apache.activemq.jndi.ActiveMQInitialContextFactory -iu tcp://localhost:61616?jms.useAsyncSend=true -cf ConnectionFactory -d dynamicQueues/testqueue -tc jms.r11.Sender -nt 1 -us system -pw manager -tx true -pp true

Receiver.bat:

Module to measure “-tc jms.r11.Receiver” receives messages from a named queue destination “-d dynamicQueues/testqueue”.
The message referenced in this batch file “Receiver.bat” is persistent “-pp”, and transacted “-tx”.

java -cp "..\..\activemq-all-5.3.0-fuse-01-00.jar;./perfharness.jar" JMSPerfHarness -pc JNDI -ii org.apache.activemq.jndi.ActiveMQInitialContextFactory -iu tcp://localhost:61616 -cf ConnectionFactory -d dynamicQueues/testqueue -tc jms.r11.Receiver -nt 1 -us system -pw manager -tx true -pp true

The second case: Find the max rate for my route camel.

If we consider this following route camel: the input is the queue orders and the output is the queue orderstatus.



We can find the max rate of this route camel, by sending a message in the queue “orders” and then waits for a reply on the output queue “orderstatus” with a matching CorrelationId.
The message referenced in this batch file “Req_Reply.bat” is persistent “-pp”, transacted “-tx” and contains a JMS Header “-pf”, and the Body “-mf”.
The tool will run for 120 secs “-rl” and print stats every 5 seconds “-ss”.


Req_Reply.bat

set BROKER_URL=tcp://localhost:61616?jms.useAsyncSend=true
set USER=system
set PASSWORD=manager
set QUEUE_OUT=dynamicQueues/orders
set QUEUE_IN=dynamicQueues/orderstatus
REM -nt Number of producer threads
set NT=1
java -cp "..\..\activemq-all-5.3.0-fuse-01-00.jar;./perfharness.jar" JMSPerfHarness -pc JNDI -ii org.apache.activemq.jndi.ActiveMQInitialContextFactory -iu %BROKER_URL% -cf ConnectionFactory -tc jms.r11.Requestor -iq %QUEUE_OUT% -oq %QUEUE_IN% -to 30000 -pf C:\Dev\tools\bench\InputMessages\JMSProperties.txt -mf C:\Dev\tools\bench\InputMessages\messageBody.xml -nt %NT% -ss 5 -rl 120 -pp true -tx true -us %USER% -pw %PASSWORD%


Enjoy !!

mardi 31 janvier 2012

Developing an Audit-logging for FuseESB (servicemix) & Karaf

For many secured environments there's a requirement to log every user management action.

The idea is to have an Audit logging module, that allow the production service, to have a trace for all administrative tasks done in Fuse ESB(servicemix) or karaf over the following channels : (SSH, WebConsole, JMX)

The trace should contain information about user logged, the command performend, channel used, date, ...etc

To run the service you need to download and add event admin service jar into system folder under appropriate path like <Fuse-ESB-install>/system/org/apache/felix/org.apache.felix.eventadmin/1.2.8-fuse-00-43/org.apache.felix.eventadmin-1.2.8-fuse-00-43.jar

Then add following to etc/startup.properties file to auto start EventAdmin service (which will generate events):

org/apache/felix/org.apache.felix.eventadmin/1.2.8-fuse-00-43/org.apache.felix.eventadmin-1.2.8-fuse-00-43.jar=9

The service contains a class LoggingEventListener that implement eventhandler, that just logs the events it receives:

StringBuffer buffer = new StringBuffer();
        buffer.append(String.format("Event [%n"));
        buffer.append(String.format("Topic: %s%n", event.getTopic()));
        for (String name : event.getPropertyNames()) {
            buffer.append(String.format("%n%s = %s", name, event.getProperty(name)));
        }
       
        buffer.append("]");
        LOGGER.info(buffer.toString());

All these events are filtered following properties fixed in blueprint.xml:

<bean id="handler" class="com.abouchama.LoggingEventListener" />

    <service ref="handler" interface="org.osgi.service.event.EventHandler">
        <service-properties>
                  <entry key="event.topics" value="org/apache/*"/>
            </service-properties>
    </service>

You can build & install bundle from Github and deploy it. Once that's done you should see the output I shown in the following example:
Example of log:

17:22:34,119 | INFO | Thread-11 | LoggingEventListener | com.abouchama.LoggingEventListener 25 | Event [
Topic: org/apache/felix/service/command/EXECUTING
 
command = osgi:list
event.topics = org/apache/felix/service/command/EXECUTING
event.subject = Subject:
                    Principal: UserPrincipal[karaf]
]

In this example you can see sample entries for actions taken via SSH. Log entries contain info like:
                         - Username : karaf
                         - Command performed : osgi:list
                         - Event : org/apache/felix/service/command/EXECUTING

Enjoy :)

vendredi 20 janvier 2012

Continuous Integration/Delivery featuring Maven, Nexus and Sonar


Continuous Integration:

In an enterprise project, it is important to continually check the non regression of the product realized. Like unit tests, acceptance tests are part of the test harness to implement a project.
Below are the usual set of tasks.
  • Build
  • Unit Test
  • Run Code Quality Checks
  • Deploy
  • Run Acceptance Test
In my current project, we have chosen below tools for Continuous Integration strategy:
  • Maven to build and unit test
  • Sonar to perform code quality checks
  • Nexus as Maven repository
  • Shell Scripting to deploy
In today's post, we will go over how to use Maven and Nexus to build and publish binaries.

Maven to Build and Unit Test:

Building java projects with maven is really easy. You just need to have maven-compiler-plugin in your pom.xml. Java sources will be compiled without doing any more work If you follow standard maven guidelines for your project folder structure.
<plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-compiler-plugin</artifactId>
                        <version>2.3.2</version>
                  </plugin>
Unit testing is possible with maven-surefire-plugin. Maven-surefire-plugin can run tests with testing frameworks like Junit, TestNG etc.
<plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-surefire-plugin</artifactId>
                        <configuration>
                             <forkMode>pertest</forkMode>
                             <childDelegation>false</childDelegation>
                             <useFile>true</useFile>
                             <failIfNoTests>false</failIfNoTests>
                             <includes>
                                   <include>**/*Test.java</include>
                             </includes>
                        </configuration>
                  </plugin>

Maven to Publish artifacts to Nexus:

All maven projects have artifacts that are generated by the build. An artifact can be a jar file, war file, zip file, ear file and a pom file. All these artifacts need to be stored in a repository for versioning purposes.
Your project’s pom.xml will have details of Nexus as maven repository in distribtionManagement section. Make sure your maven settings file has authentication details to publish to Nexus repository. Maven deploy goal needs to be executed to deploy to Nexus repository.
Pom.xml:
<project>
...
<distributionManagement>

            <repository>
                  <id>releases</id>
                  <uniqueVersion>false</uniqueVersion>
                  <name>Company Releases</name>       <url>http://localhost:8081/nexus/content/repositories/releases</url>
            </repository>
            <snapshotRepository>
                  <id>snapshots</id>
                  <uniqueVersion>false</uniqueVersion>
                  <name>Company Snapshots</name>           <url>http://localhost:8081/nexus/content/repositories/snapshots</url>
            </snapshotRepository>
      </distributionManagement>
...
</project> 
Settings.xml:
</settings>
...
<servers>
            <server>
                  <id>snapshots</id>
                  <username>deploy</username>
                  <password>deploypwd</password>
            </server>
            <server>
                  <id>releases</id>
                  <username>deploy</username>
                  <password>deploypwd</password>
            </server>
      </servers>
...
</settings>

NB: to prepare your release, and create a new tag on the source code repository:
mvn release: prepare -Dresume = false (alternatively mvn release: clean
 release: prepareand to deploy the new tag in the staging repository: mvn release:perform

Continuous delivery:
I invite you to read this interesting book: http://continuousdelivery.com/2010/02/continuous-delivery/

Enjoy !! :-)