activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: SMTP Server (Apache James) spooling hints
Date Fri, 09 May 2008 09:27:51 GMT
2008/5/9 Stefano Bagnara <>:
> James Strachan ha scritto:
> >
> > 2008/5/8 Stefano Bagnara <>:
> >
> > >  I'm starting analysis on how to replace our default spool with ActiveMQ
> and
> > >  [...] in James we currently have a single "message store" and we can
> > >
> > > "lock on a message" (so no other thread will take it) "retrieve it",
> "update
> > > and unlock it" (alter its state or state+content) or "remove it". How
> would
> > > you manage this with ActiveMQ?
> > >
> >
> >
> > With ActiveMQ you'd use a queue per state/maillet, remove it from the
> > queue, do something with it then put it on some other queue(s) (either
> > changed or the same message). The simple JMS/MOM model of sending to a
> > queue or consuming from a queue turns out to be very fast; allowing a
> > highly SEDA based asynchronous model to go really fast since there's
> > no locking or leasing required - and messages can flow very
> > asynchronously to boost throughput.
> >
>  What does it happen under the hood when I use so many queues? Is the
> message fully written to disk each time I move it from a queue to another or
> does it simply update a reference when it belongs to the same store?

Yeah, currently we do that.

Another option is to use durable topics where a message is written
once and all durable topic subscribers just get a kinda pointer to it.

>  I looked at the website and found an error in this page:
>  "An error occurred: Connection refused. The system administrator has been
> notified."

>  I looked at the CWIKI sources
> (
> and I see this:
> {snippet:id=e3|lang=xml|url=activemq/camel/trunk/components/camel-spring/src/test/resources/org/apache/camel/spring/builder/spring_route_builder_test.xml}
>  Not sure but maybe you have to add in front of
> it?

Unfortunately its due to the recent svn issues we've had at Apache.
Snippets that were working totally fine in loads of confluence wikis
are now totally borked :(

feel free to vote for it :)

> > >  I understand this is a lot of questions, but I would really appreciate
> any
> > > hint, even partial. I'm collecting ideas :-)
> > >
> >
> > :)
> >
>  Thank you! Your answers are even more than what I expected! You're
> suggestion seems to be very very useful and I think you saved me weeks of
> thoughts!

You're most welcome! :)

As an aside - for a while I've been pondering about adding a maillet
support into Camel for easy Camel <-> JAMES integration.

Something wacky to think about - which might be a bit too much Camel
internals for now but bear with me..

Camel has a really neat extensible type conversion library...

so that you can grab a message body or header as any type you like; be
it a stream, string, byte[], Document, TrAX Source or whatever. Very
handy for wiring things together!

When you invoke beans in a route like this...
f  rom("activemq:SomeQueue").bean(SomeBean.class)

we use the bean integration to figure out how to invoke the bean
method from a message...

One of the little known things is that to invoke a bean, Camel first
tries to coerce the bean into a Processor and if it can it uses that

An example of this is the ActiveMQ component for Camel which allows
you to invoke any JMS MessageListener within any Camel route -
irrespective of what message is being used...

This is implemented by writing a Camel Type Converter that can turn
any MessageListener instance into a Camel Processor - see the
toProcessor() method

So we could have awesome JAMES integration in Camel by doing the same
thing; creating converters between Camel's Message / Exchange types
and JAMES/JavaMail's APIs for messages, or for creating a Processor
from a Maillet so that we can invoke a Maillet within any Camel route
- whether the message is coming from JMS, file system, database or
JavaMail/JAMES etc

>  I'll start with your hints and I'll come back with more questions as soon
> as I'll have rode the camel! ;-)

Great! :)


Open Source Integration

View raw message