Routing ignoring page on first messages when in global size

[clebert.suconic]

When you have size > globalMaxSize, routing is aways routing at least one message before it enters into page mode.

We shouldn't messages being routed when size > globalMaxSize. Page should send the messages to a file on this situation, and the current code is aways sending a few messages before it enters into page mode.


I need to investigate a little bit more. I will post an update shortly.

[clebert.suconic]

After I fixed this, I had a few messages being paged on management, and I had a few small bugs around the executors and depaging (which I'm fixing now).


But now there is another issue regarding management destinations. (as noted on this user thread also):

http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4248264#4248264


Mangement address and temporary addresses shouldn't go into page mode IMO.


I thought the management address won't have a queue, if there are no consumers.. what would mean messages are dropped on that case. (Right?)


And we shouldn't probably page temporary queues. As when the connection is dead.. the data should be deleted.. right? An user should aways have a consumer on a temporary queue?



This should be an easy change If there is an easy way to determine if an address is management or temporary. (if we all agree with the change).

[timfox]

But now there is another issue regarding management destinations. (as noted on this user thread also):

http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4248264#4248264


Mangement address and temporary addresses shouldn't go into page mode IMO.


I thought the management address won't have a queue, if there are no consumers.. what would mean messages are dropped on that case. (Right?)


And we shouldn't probably page temporary queues. As when the connection is dead.. the data should be deleted.. right? An user should aways have a consumer on a temporary queue?



This should be an easy change If there is an easy way to determine if an address is management or temporary. (if we all agree with the change).

There is no need to treat paging on temporary or management addresses in a special way.

If you don't want those addresses to page simply specify the desired paging parameters in the address settings in the default config for those addresses.

[jmesnil]

I thought the management address won't have a queue, if there are no consumers.. what would mean messages are dropped on that case. (Right?)

Just a clarification as the management address behviour is quite particular.

There is no queue bound to the management address.
When a message is sent to the management address, it bypasses regular code path and is handled by the management service. A server message reply is created containing the management operation result and *this reply* is routed to the management message's reply-to.
The management message itself is never routed.

 private void handleManagementMessage(final ServerMessage message) throws Exception
 {
 ...

 ServerMessage reply = managementService.handleMessage(message);

 SimpleString replyTo = (SimpleString)message.getProperty(ClientMessageImpl.REPLYTO_HEADER_NAME);

 if (replyTo != null)
 {
 reply.setDestination(replyTo);

 send(reply);
 }
 }

The issue is that the reply message is paged and the management client will never receive the operation result.
In addition, when JMX is enabled, the MBean uses underneath the Core API to ensure management operations are replicated. This also means that, in that case, the server will always have a "management reply queue" so that the MBean can receive the operation result synchronously.

If we want the management to work transparently, we must not page messages send to "management reply" address (as I proposed in http://www.jboss.org/index.html?module=bb&op=viewtopic&t=159288&postdays=0&postorder=asc&start=0).
If we do not want to treat the management case specifically, the user must configure the management reply address settings to disallow paging. But requiring explicit configuration for management reply address puts the burden on the user...

[timfox]

I'm not really sure what is the big issue here.

The management problem only occurs if global max page size is set, and I thought we already agreed that we will document that global max page size should be avoided, and is a hard limit.

[clebert.suconic]

"timfox" wrote:
I'm not really sure what is the big issue here.

The management problem only occurs if global max page size is set, and I thought we already agreed that we will document that global max page size should be avoided, and is a hard limit.

Suppose there is a notification on page mode being started. The admin would take that notification and take actions about it.

The notification about paging will never arrive because it is paged.


If there is an easy way to determine an address or a message belongs to management.. I can just change PageStore::page to ignore the message.

Is there any property on the Message identifying it as a management operation? If there is this would be a two lines change.

I already have at the moment two tests failing because management is being paged. Doing such change would help me on fixing those tests.

[timfox]

I actually think we should remove global max page size altogether.

It doesn't seem to be very useful and is prone to locking the system anyway.

[clebert.suconic]

+1