camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henryk Konsek <>
Subject Re: Event Driven Use Case
Date Tue, 05 Feb 2013 08:29:30 GMT
> 1. How can I implement the state saving and reconstructing using memento in
> a generic way without serialization?

If you can probably narrow the generic requirements of your messages
to structure similar to the one below:

class MessageState(correlationId String, metaDataCsv: String)

Storing fixed amount of Strings per message is trivial for almost any
persistent store.

Working with serialized objects can be tricky. Badly constructed
message can blow your system away. The typical scenario of
serialization failure is the "reference leak" - you want to serialize
single object, but end up attempting to serialize entire Spring
context :) . It is also challenging to efficiently look up for the
serialized object by correlation id, while serializing
Map<CorrelationId, Exchange> is multi-threaded environment is asking
for trouble :) .

Another option for generic object store is DB4O component [1]. DB4O is
an object database and can store any object out-of-the-box.

You can also consider to convert POJO message to Java Map and sending
it to the Redis component.

> 2. This is very heavy traffic app and keeping the state in local memory is
> not an option as it will run out of memory as responses from services may
> take minutes.

Memento objects can be really small. You might consider recalculating
this, if performance become an issue :)

> Also, response from services can come back to a server which
> does not have the state (it is in local cache of another server).

That's the reason I suggested EHCache (with persistent store disabled)
or Guava Cache with common state shared via JGroups multicast. Both of
these solutions keep local copy of in-memory cache synchronized with
other machines.

> I thought
> of using memcache (or other distributed cache). However, it does not have
> call-back mechanism if an entry expires.

In the previous post I mentioned that Guava Cache provides eviction callbacks.

> Also, it will cause problems to
> figure out timed-out transactions when my app is down and entries cached in
> memcache expires before app comes up.

You mentioned that you're using cluster. This sentence indicates that
application should not be "totally" down at any moment. You shouldn't
be affect by this scenario then. BTW The majority of the cache
implementation allow you to configure eviction strategy (or even
create your own).

Best regards.


Henryk Konsek

View raw message