Jdbc Message store accumulating messages in memory [INT-2151]

[spring-operator]

Krishnan R opened INT-2151 and commented

Jdbc message store accumulates all messages in memory, during every poll. Since the pollers are auto-startup by default, this also means that it will happen on application startup by default.

---

Affects: 2.0.5

Reference URL: http://forum.springsource.org/showthread.php?114728-jdbc-message-store-memory-issues

This issue is a sub-task of #6168

Issue Links:

• Refactor Aggregator and Resequencer to better accommodate full span of use-cases [INT-2152] #6135 Refactor Aggregator and Resequencer to better accommodate full span of use-cases

[spring-operator]

Oleg Zhurakousky commented

You must send me the configuration that reproduces this issue otherwise it has to be resolved as 'can't reproduce'. I just tested it and nothing gets executed on the database until any method on MessageStore is executed.
For example:

setUp("defaultJdbcMessageStore-light.xml", getClass());
store = context.getBean("messageStore", MessageStore.class);

And the only output is:

11:22:45,308  INFO main embedded.EmbeddedDatabaseFactory:125 - Creating embedded database 'dataSource'

Then. . .

System.out.println("Message count: " + store.getMessageCount());

And the only output is:

11:27:25,242 DEBUG main core.JdbcTemplate:634 - Executing prepared SQL query
11:27:25,243 DEBUG main core.JdbcTemplate:569 - Executing prepared SQL statement [SELECT COUNT(MESSAGE_ID) from INT_MESSAGE where REGION=?]
11:27:25,244 DEBUG main datasource.DataSourceUtils:110 - Fetching JDBC Connection from DataSource
11:27:25,244 DEBUG main datasource.SimpleDriverDataSource:138 - Creating new JDBC Driver Connection to [jdbc:hsqldb:mem:dataSource]
11:27:25,270 DEBUG main datasource.DataSourceUtils:332 - Returning JDBC Connection to DataSource
Message count: 3

[spring-operator]

Oleg Zhurakousky commented

As I stated I am sure this issue is no issue at all so I'll address it by just creating another test that proves it

[spring-operator]

Mark Fisher commented

Even if not happening for #1 (app context bootstrap), this is still happening for #2 (accumulating all messages on every poll).

[spring-operator]

Oleg Zhurakousky commented

That is a whole different issue and is related to the way MGQ is currently implemented and will probably end up as part of a much bigger issue which is refactoring/improving all implementations of MessageStore. Basically the same reason why we pushed #5858, so I definitely dont want to tie it together.

[spring-operator]

Mark Fisher commented

It's not a different issue. This one is "Jdbc Message store accumulating messages in memory". The #2 point in the description is still a valid problem (can lead to OOM) even if the #1 point in the description might not be true (even though it's most likely a case of #2 itself since pollers start automatically by default).

[spring-operator]

Krishnan R commented

bq: 16-Sep-2011 19:08:48,144 DEBUG : : : : : [org.springframework.beans.factory.support.Abstract AutowireCapableBeanFactory:createBean:458] - Finished creating instance of bean 'RecordUpdateEventMsgStore'
16-Sep-2011 19:08:48,144 DEBUG : : : : : [org.springframework.beans.factory.support.DefaultS ingletonBeanRegistry:getSingleton:214] - Creating shared instance of singleton bean 'RecordUpdateEventQ'
16-Sep-2011 19:08:48,144 DEBUG : : : : : [org.springframework.beans.factory.support.Abstract AutowireCapableBeanFactory:createBean:430] - Creating instance of bean 'RecordUpdateEventQ'
16-Sep-2011 19:08:48,144 DEBUG : : : : : [org.springframework.beans.factory.support.Abstract AutowireCapableBeanFactory:createBean:430] - Creating instance of bean '(inner bean)#1'
16-Sep-2011 19:08:48,144 DEBUG : : : : : [org.springframework.beans.factory.support.Abstract BeanFactory:doGetBean:242] - Returning cached instance of singleton bean 'RecordUpdateEventMsgStore'
16-Sep-2011 19:08:48,144 DEBUG : : : : : [org.springframework.beans.TypeConverterDelegate:do ConvertValue:377] - Converting String to [int] using property editor [org.springframework.beans.propertyeditors.CustomNu mberEditor@18a3bee]
16-Sep-2011 19:08:48,144 DEBUG : : : : : [org.springframework.beans.factory.support.Abstract AutowireCapableBeanFactory:createBean:458] - Finished creating instance of bean '(inner bean)#1'
16-Sep-2011 19:08:48,144 DEBUG : : : : : [org.springframework.jdbc.core.JdbcTemplate:query:6 34] - Executing prepared SQL query
16-Sep-2011 19:08:48,144 DEBUG : : : : : [org.springframework.jdbc.core.JdbcTemplate:execute :569] - Executing prepared SQL statement [SELECT MESSAGE_ID, CREATED_DATE, GROUP_KEY, MESSAGE_BYTES, MARKED from INT_MESSAGE_GROUP where GROUP_KEY=? and REGION=? order by CREATED_DATE]
16-Sep-2011 19:08:48,144 DEBUG : : : : : [org.springframework.jdbc.datasource.DataSourceUtil s:doGetConnection:110] - Fetching JDBC Connection from DataSource
16-Sep-2011 19:08:58,269 DEBUG : : : : : [org.springframework.jdbc.support.lob.DefaultLobHan dler:getBlobAsBytes:117] - Returning BLOB as bytes

[spring-operator]

Krishnan R commented

Thats the log starting from the application context bootstrap.. I have already shared it in the forum thread..

I have alos shared the configuration.A jdbc message store backed Q channel without even a poller configured accumulates all messages once, thats during the bootstrap.

Basically this is the query thats fired for every poll and during bootstrap:
SELECT MESSAGE_ID, CREATED_DATE, GROUP_KEY, MESSAGE_BYTES, MARKED from INT_MESSAGE_GROUP where GROUP_KEY=? and REGION=? order by CREATED_DATE

which is certain to bring all messages in the group

[spring-operator]

Oleg Zhurakousky commented

This statement is coming when you attempt a first receive() from the queue. It is not coming at the bootstrap time. There is a test case for it.
So yes messages are loaded at the first poll(), but not at the initialization time.

[spring-operator]

Oleg Zhurakousky commented

Please look at this PR olegz@4b16742
You can clearly see the configuration and the test case with validation which shows that poll() is executed only when you attempt a first receive() and that is when you see the SELECT statement - not before.

[spring-operator]

Mark Fisher commented

I just updated the description to clarify the relationship between "every poll" and what's happening at application startup.

[spring-operator]

Krishnan R commented

I could be wrong.
But please note the logs were captured when no pollers were configured against the queue.

[spring-operator]

Oleg Zhurakousky commented

Just converted it to a sub-task of #6168 which describes the real issue where all Messages are loaded into memory once the forst poll() is executed on MessageGroupQueue.
Once #6168 is resolved, this could be resolved without any further work.