Hi Claus, hi all, Thank you for explaining why there's no equals in DefaultExchangeHolder's. If DefaultExchangeHolder is not the representation of a queued Camel exchange waiting to be processed, what is? We weren't trying to create new ExchangeHolders or duplicate exchanges. The problem was simply removing one specific element from our hazelcast-based dead-letter-queue.
In case anyone else runs into the same problem when requeuing messages in hazelcast queues: We experimented with the hazelcast configuration, setting hazelcast's QueueStore property "binary" to "true", now things seem to be working. It's a bit fishy, now it even appears to be working with settings that definitely weren't working two days ago, but well .. Thanks, Gerda 2014-04-29 13:48 GMT+02:00 Claus Ibsen <claus.ib...@gmail.com>: > Its not intended for storing in lists/queues etc. > > Its just for serializing / deserializing an exchange for transfer over the > wire. > Also each holder ought to be unique as you shouldn't really create > multiple holders of the same exchange. And each exchange in Camel is > unique. > > On Tue, Apr 29, 2014 at 10:54 AM, Gerda Ilger <gerda.il...@ecosio.com> > wrote: > > Hi all, > > > > We're using hazelcast:seda with the option "transferExchange=true", which > > works great for moving our data over the wire. > > > > I'm currently working on plain java code for moving exchanges between > > hazelcast queues, and I ran into the following problem: > > Some operations on the hazelcast queue, like 'remove(obj)' and > > 'contains(obj)', don't work because DefaultExchangeHolder does not have > an > > implementation of 'equals'. > > > > Is there a reason why DefaultExchangeHolder does not implement 'equals'? > > > > We're on Camel 2.13. > > > > Thanks, > > Gerda > > > > -- > Claus Ibsen > ----------------- > Red Hat, Inc. > Email: cib...@redhat.com > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen > hawtio: http://hawt.io/ > fabric8: http://fabric8.io/ >
