Dave Stanley's Blog

This Artix/E demo is pretty cool.

An iPhone is shown using Artix/E to talk to a Chumby. The accelerometer data from the iPhone is streamed over the wire to the chumby’s chumball widget.

[INFO] The service unit my-jms-consumer-su does not have a dependency which is packaged as a jbi-component or a project property 'componentName'

If you see the above error when trying to build your servicemix service assembly, the
trick is to look at the pom.xml for the component with the problem. In this case the ServiceMix SU is’my-jms-consumer-su’.

In order to fix the Service Assembly build error I added the componentName to the SU’s pom.xml below properties section, so

1
2
3

        <properties>
                <servicemix-version>3.3.1.0-fuse</servicemix-version>
        </properties>

became:

1
2
3
4

        <properties>
                <servicemix-version>3.3.1.0-fuse</servicemix-version>
                <componentName>servicemix-jms</componentName>
        </properties>

This problem only tends to occur when you have multiple su’s within the assembly that depend on the same servicemix component (e.g. servicemix-jms). Make sure you add the componentName to all of the Service Unit poms.xml’s that use that component.

I’ve been running performance tests with Fuse ESB 3.3.1 and the spring based JMS endpoints over the last day or two.

One gotcha I’ve seen mentioned before with ActiveMQ is on the producer side you need to use a PooledConnectionFactory when using
springs jmsTemplate. The same applies when using the Servicemix jms:provider endpoint (as
its using jmsTemplate under the covers).

If your jms provider configuration looks similar to this:

1
2
3
4
5
6
7
8
9
10
11

 <jms:provider
      service="test:MySpringProviderService"
      endpoint="mySpringProvider"
      destinationName="queue/OUT"
      connectionFactory="#connectionFactory"
      pubSubDomain="false"
      stateless="false" />

 <bean id="connectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">
    <property name="brokerURL" value="tcp://localhost:61616" />
 </bean>

change the connectionFactory to something like this:

1
2
3
4
5
6
7
8
9

 <bean id="connectionFactory" class="org.apache.activemq.pool.PooledConnectionFactory">
    <property name="connectionFactory">
      <bean class="org.apache.activemq.ActiveMQConnectionFactory">
        <property name="brokerURL" value="tcp://localhost:61616" />
      </bean>
    </property>
    <property name="maxConnections" value="1" />
    <property name="maximumActive" value="1" />
  </bean>

Then by the numbers for my test flow (Jms Consumer->EIP->Bean->JMS Provider & processing/10K worth of messages) …

Pooled ConnectionFactory:

     [java] Overall time: 40360 ms
     [java] Messages per sec: 247.77006937561944
     [java]
     [java] Time: 41.064
     [java]
     [java] OK (1 test)
     [java]    

Non-Pooled ConnectionFactory:

     [java] Overall time: 908363 ms
     [java] Messages per sec: 11.008814757976712
     [java]
     [java] Time: 909.34
     [java] OK (1 test)
     [java]
 

Those couple of lines of XML make a big difference. Without the pool, the JMS connection is torn down each time and that accounts for the disparity.

A second area to look out for is the jms:consumer endpoint configuration. Make sure you set the cacheLevel to CACHE_CONNECTION (1) or CACHE_CONSUMER (3). The default is CACHE_NONE. Below we set the cacheLevel for the underlying DefaultMessageListenerContainer to CACHE_CONSUMER

1
2
3
4
5
6
7

  <jms:consumer service="test:MySpringConsumerService"
        endpoint="mySpringConsumer"
        targetService="test:MySpringProviderService"
        destinationName="queue/SPRING_IN"
        connectionFactory="#connectionFactory"
        concurrentConsumers="1"
        cacheLevel="3"/>

I hope these two tips will help you fine tune your Servicemix performance.

So I got my Chumby a couple of days ago and its very solid so far. The chumby arrived promptly within a couple of days of ordering it – in a nicely packaged canvas bag with no molded plastic packaging or wire ties to cut through.

As far as setup goes, it was very straightforward. It connected to my wireless network first time, and after configuring some flash widgets to play using my account on the chumby website I was up and running. The chumby started to cycle

through the set of selected widgets (in my case – current weather for my zipcode, blog rss feeds (particularly good for blog

comments feeds), google news, stock quotes, flickr, utube most popular etc). As far as the widgets go, the user experience is different to browsing the web. Your fed small digestible chunks of the web at a time and after a couple of days of usage its quite addictive.

With the basics over with (and as the chumby runs an embedded Linux 2.6 kernel) the next step was to see if I could

connect to the chumby. Thanks to the linux librarian, I discovered it was

possible to ssh. I just needed to enable sshd using the “pi” icon in the chumby options panel. After folowing

href="http://wiki.chumby.com/mediawiki/index.php/Chumby_tricks">these steps, I fired up putty, entered the default

password of “root” and I had a shell to the chumby. Very cool!

The Linux librarian also mentioned streaming audio from a SlimServer so I figured I’d give that a try also. This took a bit

of fiddling around but I eventually got it working.

Here’s the steps to get basic mp3 streaming to the chumby using SlimServer (and things that screwed me up):

1) Install SlimServer 6.5 from here

2) Start the slimserver. It will listen on http://localhost:9000 and you can connect to this url using a web browser to bring up the slimserver admin interface. When you first connect you can give it the location of your music folder and it will find all the music on your computer

3) ssh to the chumby. Start the ‘btPlay’ mp3 streaming utility to connect back to your slimserver.

>btPlay http://:9000/stream.mp3

4) In the slimserver admin configure the content you want to stream to the chumby client. I made the mistake of adding a file with a .m4a extension first. After some time I resorted to running the slimserver with debug output on the command line and the mistake was obvious enough .. not obvious without doing that. Switching to an mp3 and voila! I had mp3 audio streaming working. The Chumby is not a squeezebox but the sound is fine for background listening.

5) Next step was to try and get radio streaming working. I figured I’d have a stab at getting AlienBBC working. I installed the AlienBBC install pack and tried to stream the Chris Moyles show .. silence…(followed by some swearing ….more silence …)* and back to the slimserver debug output ..

>slim --d_source --d_plugins -d_remotestream

6) After much pissing about (including an upgrade to SqueezeCenter7.0 which I unfortunately could not get to work), I discovered I needed to:

- Build and install lame.exe into the “\server\Bin\MSWin32-x86-multi-thread” directory

- Modify \server\Plugins\Alien\RTSP.pm as follows:

        # Check client - only stream to known slim clients
	#if (!defined($client) || !$client->isPlayer()) {
	#	$::d_remotestream && msg "Alien only streams to Slim players\n";
	#	return undef;
	#}

Finally .. success!

The Fuse September Release is now available. New in this release:



- Message Broker 5.0 (based on Apache ActiveMQ trunk)

- FUSE ESB 3.3 (Based on Apache ServiceMix 3.2 )

- Mediation Router 1.2 (based on Apache Camel 1.2)

- Services Framework 2.0.2 (based on Apache Incubator CXF 2.0.2)

(If your in an RSS Reader and swf doesn’t embed click here)

Update: Hmm, looks like DylanMessaging are having trouble. If you don’t see the message .. try again later!

Some videos from one of the creators of the upcoming hackable/open source Chumby.

A chip-on-board (CoB) wire bonder:

Amazingly, the PCB’s of modern electronic toys don’t seem to have a single visible chip (although they have all kinds of smart logic and sounds samples). The chips have been replaced with little blobs of epoxy – i.e COB (silicon without the casing). I’d wondered about this when I was pulling apart one of Ellie’s VTech toys a few months back.. mystery now revealed as the Chumby has the same thing.

Injection Molding:

Also pretty interesting on how the plastic casings are made.

Quality control on the modern electronics assembly line:

Its easy to take for granted all the work that must go on behind the scenes to produce something like an iPod or any other electronic gizmo. Interesting perspective on how the Chumby folks managed their quality control remotely, especially with all the recent news headlines on this topic.