Or maybe.. that operation could just be ignored in case of failure (from DuplicateIDChannelImpl::addToCacheInMemory:

private synchronized void addToCacheInMemory(final byte[] duplID, final long recordID) throws Exception
 {
 cache.add(new ByteArrayHolder(duplID));

 Pair<ByteArrayHolder, Long> id;

 if (pos < ids.size())
 {
 // Need fast array style access here -hence ArrayList typing
 id = ids.get(pos);

 cache.remove(id.a);

 // Record already exists - we delete the old one and add the new one
 // Note we can't use update since journal update doesn't let older records get
 // reclaimed
 id.a = new ByteArrayHolder(duplID);

 storageManager.deleteDuplicateID(id.b); <<< this is the only throwing exception

 id.b = recordID;
 }
 else
 {
 id = new Pair<ByteArrayHolder, Long>(new ByteArrayHolder(duplID), recordID);

 ids.add(id);
 }

 if (pos++ == cacheSize - 1)
 {
 pos = 0;
 }
 }

I created a JIRA so we won't forget this:

https://jira.jboss.org/jira/browse/HORNETQ-188

Yes.. the commit itself could fail, what is ok. The client would receive the Exception about the call not being successful what is ok.

Regarding the second one, RefsOperation, this is far more complex. It calls postAcknowledge which removes the message from the journal if it is the last reference, again what should we do here, log a message.

The other stuff that happens on refsOperation is to do with handling paging and handling large messages. Nearly every operation on both these all throw an exception. following the code down its mainly because of handling file resources etc. This exception handling probably needs refactoring but i'm not sure how best to change it as yet or if it should be left until post 2.0.

thoughts?