JDBCMessageStore and MimeMailMessage

[Gary Russell]

Yes, you cannot restore the ID this way; it will only be restored if the entire message is (de)serialized. That said, having a new ID won't hurt anything at all.

Another alternative is to simply provide transformers before and after the message store.

gateway->transformMMMToYourSerializable->JDBC-backed-channel->transformFromYourSerializableToMMM->toMailAdapter.

That way, you don't need any custom serialization.

[alexbarnes]

That does sound like a good alternative, I'll give it a go.

I just want to confirm something:

Yes, you cannot restore the ID this way; it will only be restored if the entire message is (de)serialized. That said, having a new ID won't hurt anything at all.

If I put a message on my JDBC backed queue with the polling mail adaptor stopped I get a message in my database as expected. If I then start the outbound mail adaptor via the control channel the polling outbound mail adaptor finds my message over and over again. I would have expected it to remove it and I was expecting it to remove it using the id? Is that incorrect?

This is the SQL in the JDBCMessageStore:

DELETE_MESSAGE = "DELETE from %PREFIX%MESSAGE where MESSAGE_ID=? and REGION=?"

This is called by PollingConsumer#doPoll() as part of releasing a processed message. I would have thought that deserializing a message and setting a different id would cause issues? Specifically the above SQL will never delete the message from the int_message table and the PollingConsumer will keep finding it?

It seems that if you allow a hook for a custom (de)serializer then you need to allow this id to be set. That is certainly the impression I get from the comment on the field.

[Gary Russell]

Yes, you are correct; sorry - only Java serialization will work in this case and, of course, it doesn't work for you because MMM is not serializable.

My transformer pair suggestion should work ok.

[alexbarnes]

In terms of supplying custom (de)Serializers would you agree that you need to be able to set the id on a new message? Given that you'll have serialized the headers and will be deserializing them and setting them on your new message?

[alexbarnes]

Further to this: I've cloned the spring integration repo and updated the MessageHeaders constructor. I can now serialize to db then start the polling channel adaptor using the control channel. This allows the deserialization code to set the id of the message to that of the message in the db:

The following logs follow:

INFO : org.springframework.integration.endpoint.PollingConsumer - started outboundMailChannelAdaptor
DEBUG: org.springframework.integration.handler.ServiceActivatingHandler - handler 'ServiceActivator for [org.springframework.integration.handler.ExpressionCommandMessageProcessor@125cf56]' produced no reply for request Message: [Payload=@outboundMailChannelAdaptor.start()][Headers={timestamp=1330698789238, id=4ef870e1-2625-496a-81b9-285f8e4b6500}]
DEBUG: org.springframework.integration.channel.DirectChannel - postSend (sent=true) on channel 'controlChannel', message: [Payload=@outboundMailChannelAdaptor.start()][Headers={timestamp=1330698789238, id=4ef870e1-2625-496a-81b9-285f8e4b6500}]
TRACE: org.springframework.integration.monitor.DirectChannelMetrics - StopWatch 'controlChannel.send:execution': running time (millis) = 23; [] took 23 = 100%
TRACE: org.springframework.integration.monitor.QueueChannelMetrics - Recording receive on channel(outboundMailChannel) 
TRACE: org.springframework.integration.channel.QueueChannel - preReceive on channel 'outboundMailChannel'
Hibernate: select mailsender0_.id as id5_, mailsender0_.error as error5_, mailsender0_.errorTime as errorTime5_, mailsender0_.userName as userName5_, mailsender0_.version as version5_ from MailSendError mailsender0_ where mailsender0_.errorTime>=?
DEBUG: org.springframework.integration.jdbc.JdbcMessageStore - Removing message from group with group key=9ea43c5e-5587-3754-ada7-99f7801195f2
DEBUG: org.springframework.integration.jdbc.JdbcMessageStore - Updating MessageGroup: 9ea43c5e-5587-3754-ada7-99f7801195f2
DEBUG: org.springframework.integration.jdbc.JdbcMessageStore - Updating MessageGroup: 9ea43c5e-5587-3754-ada7-99f7801195f2
DEBUG: org.springframework.integration.channel.QueueChannel - postReceive on channel 'outboundMailChannel', message: [Payload=org.springframework.mail.javamail.MimeMailMessage@1f2139c][Headers={id=abeb7a40-0e85-4811-ab5a-c5088a2fe3a9, timestamp=1330698789373, JdbcMessageStore.CREATED_DATE=1330697565516, JdbcMessageStore.SAVED=true}]
DEBUG: org.springframework.integration.endpoint.PollingConsumer - Poll resulted in Message: [Payload=org.springframework.mail.javamail.MimeMailMessage@1f2139c][Headers={id=abeb7a40-0e85-4811-ab5a-c5088a2fe3a9, timestamp=1330698789373, JdbcMessageStore.CREATED_DATE=1330697565516, JdbcMessageStore.SAVED=true}]
TRACE: org.springframework.integration.monitor.SimpleMessageHandlerMetrics - messageHandler(org.springframework.integration.mail.MailSendingMessageHandler#0) message([Payload=org.springframework.mail.javamail.MimeMailMessage@1f2139c][Headers={id=abeb7a40-0e85-4811-ab5a-c5088a2fe3a9, timestamp=1330698789373, JdbcMessageStore.CREATED_DATE=1330697565516, JdbcMessageStore.SAVED=true}]) :
DEBUG: org.springframework.integration.mail.MailSendingMessageHandler - org.springframework.integration.mail.MailSendingMessageHandler#0 received message: [Payload=org.springframework.mail.javamail.MimeMailMessage@1f2139c][Headers={id=abeb7a40-0e85-4811-ab5a-c5088a2fe3a9, timestamp=1330698789373, JdbcMessageStore.CREATED_DATE=1330697565516, JdbcMessageStore.SAVED=true}]
TRACE: org.springframework.integration.monitor.QueueChannelMetrics - Recording receive on channel(outboundMailChannel) 
TRACE: org.springframework.integration.channel.QueueChannel - preReceive on channel 'outboundMailChannel'
TRACE: org.springframework.integration.monitor.QueueChannelMetrics - Recording receive on channel(outboundMailChannel) 
TRACE: org.springframework.integration.channel.QueueChannel - preReceive on channel 'outboundMailChannel'
DEBUG: org.springframework.integration.jdbc.JdbcMessageStore - Updating MessageGroup: 9ea43c5e-5587-3754-ada7-99f7801195f2
TRACE: org.springframework.integration.channel.QueueChannel - postReceive on channel 'outboundMailChannel', message is null
DEBUG: org.springframework.integration.endpoint.PollingConsumer - Poll resulted in Message: null
DEBUG: org.springframework.integration.endpoint.PollingConsumer - Received no Message during the poll, returning 'false'

This is the behaviour I saw with the SimpleMailMessage and what I was expecting i.e. once the Message is picked up it's deleted and the poll logs return to finding no message.

My change to MessageHeader was:

if (!this.headers.containsKey(ID)) {
			if (MessageHeaders.idGenerator == null){
				this.headers.put(ID, UUID.randomUUID());
			}
			else {
				this.headers.put(ID, MessageHeaders.idGenerator.generateId());
			}
		}

Thoughts? I appreciate that not allowing the Id to be set is a deliberate design decision. But it seems to be at odds with allowing custom deserializers.

I prefer the serialization and deserialization approach to the multi transformer approach. This allows me to keep my arrangement as follows:

Gateway -> Direct Channel -> Transformer -> Queue Channel (JDBCMessageStore) -> Outbound Mail Channel Adaptor

In this setup the message was passed directly through the transformer and then the Channel Adaptor polled the queue channel looking for mail to send. I can then start and stop the outbound adaptor using a control channel.

[alexbarnes]

Raised INT-2460 to capture my thoughts on this.