[mq-dev] Re: Persistent messages exceeding 1MB are lost

  • From: "Okubo, Takuji" <takujio@...>
  • To: Amy Kang <amy.kang@...>
  • Cc: <dev@...>
  • Subject: [mq-dev] Re: Persistent messages exceeding 1MB are lost
  • Date: Mon, 12 Aug 2013 15:00:45 +1000

Hi Amy, 

 

Thank you very much for your help. We will download it.

 

Regards, 
Takuji

 

From: Amy Kang [mailto:amy.kang@...] ;
Sent: Saturday, August 10, 2013 2:38 PM
To: Okubo, Takuji
Cc: dev@...
Subject: Re: [mq-dev] Persistent messages exceeding 1MB are lost

 

Hi Takuji,

MQ 5.0.1 build b01 can be downloaded from
http://download.java.net/mq/open-mq/5.0.1/

and source code for this build is available at
https://hg.java.net/hg/mq~mq5/ ;<https://hg.java.net/hg/mq%7Emq5/>  

Thanks,
amy

On 07/21/2013 11:47 PM, Okubo, Takuji wrote:

        Hi Amy, 

         

        Thank you very much for prompt reply. I am sorry if this is
something I need to ask Oracle support team, but we would like to get
the source code of version 5.0.1. Is it a patch release. I understand
the patch release is only available for customers with support contract.
Do you need a support contract to download this 5.0.1 version? 

         

        Our product 'Fujitsu Interstage Application Server' which is one
of the most popular Java EE servers in Japan includes Glassfish and
OpenMQ. We have tested Glassfish and OpenMQ extensively and fixed a
number of existing bugs for our products. At the same time, we have been
making contributions to Glassfish and OpenMQ by sending the bug fixes to
the communities or adding new features. We believe having the latest
version of OpenMQ source code publically available not only helps us to
make our product Interstage better but also improves the quality of
OpenMQ. More users and external developers like us would be able to give
feedbacks against the latest version. 

         

        Regards, 

        Takuji

         

        From: Amy Kang [mailto:amy.kang@...] ;
        Sent: Saturday, July 20, 2013 1:41 AM
        To: Okubo, Takuji
        Cc: dev@...
        Subject: Re: [mq-dev] Persistent messages exceeding 1MB are lost

         

        Hi Takuji,
        
        On 07/18/2013 05:05 PM, Okubo, Takuji wrote:

                Hi Amy, 

                 

                Thank you very much for very quick response. We will
create a patch for our products which use OpenMQ and make it available
for our customers to apply it. However, this will be a time consuming
process, so in the meantime, we also would like to suggest a workaround
for our customers. As I asked in the previous email, we are thinking of
advising our customers to set
imq.persist.file.destination.message.filepool.limit=0 which turns off
the filepool to avoid this problem. We also think all other functions
are not affected when this parameter is set. Could you please advise us
if our understanding is correct? 

                 

        
        correct, but I'd suggest do test this in your dev environment
(just because '0' might not have been a commonly used setting),
especially if it's on Windows.   Performance will get affected because
an individual message file that is returned to the 'pool' will be
deleted when imq.persist.file.destination.message.filepool.limit=0.
        
        MQ-322 has now been fixed in current dev version 5.0.1.  For
patch releases, please contact Oracle support. 
         
        Thanks,
        amy
        
        
        
        

        Regards, 

        Takuji

         

        From: Amy Kang [mailto:amy.kang@...] ;
        Sent: Thursday, July 18, 2013 3:29 PM
        To: Okubo, Takuji
        Cc: dev@...
        Subject: Re: [mq-dev] Persistent messages exceeding 1MB are lost

         

        Hi Takuji,
        
        Thanks for the additional information.  I now can reproduce  the
problem.   The tentative fix you provided looks good.     The 1M size is
the message size boundary to determine whether the message should to use
its own file.   As you have pointed out the problem is caused by the
'scanned' flag not set true when hasMoreElements() returns false with
obj == null on completion of directory first scan.   The actual 'loss'
of the messages happens at the step of producing 100 messages that's
when the unexpected 2nd directory 'scan' occurred due to incorrect
'scanned' flag.  The 2nd directory scan causes the same 'FREE' files to
be added to the FilePool 2nd time,  therefore the produced 100 messages
actually are stored into 50 files, not 100.   The problem can be
reproduced also if the count 50 is 1, count 100 is 2.   I'v filed
following jira for this issue 
        
        
        
        

        https://java.net/jira/browse/MQ-322

        
        >7.       Create a destination queue. (The bug is not
reproduced, if you skip this step. )
        >    imqcmd create dst -t q -n JMSQueue
        
        That's because if the destination is auto-created,  the
destination will be reapped at step 10, then there is no pre-existing
'FREE' message files for the destination which is a pre-condition for
the bug to occur.
        
        Thanks,
        amy
        
        On 07/17/2013 01:07 AM, Okubo, Takuji wrote:

                Hi Amy, 

                 

                We've reproduced the problem in using this test program.


                 

                MessageProducer producer = s.createProducer(dst);

                ObjectMessage msg = s.createObjectMessage();

                byte[] b = new byte[1024*1024];

                msg.setObject(b);

                 

                for (int i = 0; i < count; i++) {

                    producer.send(msg, DeliveryMode.PERSISTENT, 4,
(long) 3000000);

                }

                 

                Here is the more detailed steps which I have done. 

                1.       Start Glassfish 

                asasdmin start-domain

                2.       Set JMS Service Type as REMOTE by Glassfish Web
Admin

                3.       Create Connection Factory and Destination
Resource by Glassfish Web Admin

                4.       Restart Glassfish

                asadmin stop-domain

                asadmin start-domain

                5.       Clear the MQ environment

                imqbrokerd -remove instance

                6.       Start broker with default setting

                Imqbrokerd 

                7.       Create a destination queue. (The bug is not
reproduced, if you skip this step. )

                imqcmd create dst -t q -n JMSQueue

                8.       Send 50 messages in persistent mode. Each
message exceeds 1MB (1024 x 1024 byte or more).

                9.       Receive all messages which have been sent in
step 7.  

                10.   Restart broker 

                imqcmd shutdown bkr

                imqbrokerd

                11.   Send 100 messages in persistent mode. Each message
exceeds 1MB (1024 x 1024 byte or more).

                12.   Check messages. The result of imqcmd list dst is
100.

        
------------------------------------------------------------------------
---------------------

                   Name     Type    State      Producers
Consumers                  Msgs

                                            Total  Wildcard  Total
Wildcard  Count  Remote  UnAck  Avg Size

        
------------------------------------------------------------------------
---------------------

                JMSQueue    Queue  RUNNING  0      -         0      -
100    0       0      1048731.0

                13.   Restart broker 

                imqcmd shutdown bkr

                imqbrokerd

                14.   Check messages. The result of imqcmd list dst is
50.

        
------------------------------------------------------------------------
---------------------

                   Name     Type    State      Producers
Consumers                  Msgs

                                            Total  Wildcard  Total
Wildcard  Count  Remote  UnAck  Avg Size

        
------------------------------------------------------------------------
---------------------

                JMSQueue    Queue  RUNNING  0      -         0      -
50     0       0      1048731.0

                 

                 

                > How did you come to that conclusion ?

                We've looked at the step 12 and 14. 

                 

                 

                 

                Regards, 
                Takuji

                 

                From: Amy Kang [mailto:amy.kang@...] ;
                Sent: Wednesday, July 17, 2013 2:05 AM
                To: Okubo, Takuji
                Cc: dev@...
                Subject: Re: [mq-dev] Persistent messages exceeding 1MB
are lost

                 

                Hi Takuji,
                
                Thanks for reporting and looking into this.
                
                First I'd like to reproduce the problem.  I'v tried some
different message sizes over 1M (e.g. 1024*1024*2 bytes, 1024*1024+1024
bytes) sending (persistent) to a queue and didn't reproduce it - after
following your steps #1-#6,  'imqcmd list dst' shows 100 messages and a
receiver can receive 100 messages.    Therefore I need more information.
                
                >only 50 messages have been stored and the rest of 50
messages are lost.
                
                How did you come to that conclusion ?
                
                Thanks,
                amy
                
                On 07/15/2013 11:17 PM, Okubo, Takuji wrote:

                        Hi there, 

                         

                        We found a problem that some persistent messages
are lost in Open MQ 4.4 and we have also confirmed that the same problem
is reproduced in Open MQ 5.0. Our developers modified the source code to
fix the problem and we would appreciate if you could check if our fix is
correct. We have also found a workaround for this problem and we would
like to check if the workaround is correct.

                         

                        I understand a bug report should be sent to the
JIRA system. However, I am posting to the mailing list as I noticed it
takes very long time to get response in JIRA in some cases. If I need to
open a case in JIRA, please let me know. Thank you very much for your
understanding. 

                         

                        Problem:

                        Persistent messages exceeding 1MB (1024 x 1024
byte) are lost. 

                         

                        Steps to reproduce:

                        This is a typical example to reproduce the
problem but this can be reproduced in several ways.  

                         

                        1. Start message broker with default setting. 

                        2. Send 50 messages in persistent mode. Each
message exceeds 1MB (1024 x 1024 byte).

                        3. Receive all messages which have been sent in
step 2.  

                        4. Restart message broker. 

                        5. Send 100 messages in persistent mode. Each
message exceeds 1MB (1024 x 1024 byte). 

                        6. Restart message broker. 

                         

                        When the above steps are performed,  

                        We expect 100 messages are stored after
restarting, as 100 messages have been sent in step 5. 

                        However, only 50 messages have been stored and
the rest of 50 messages are lost.  

                         

                        We found more cases in which the problem is
reproduced. 

                        - Execute imqcmd purge dst in step 2. 

                        - Message expires in step 2. and moves to DMQ. 

                         

                        Cause:

                        We found a problem in loading persistent
messages and file pool is executed twice. 

                         

                        Workaround:

                        We found a workaround by specifying
imq.persist.file.destination.message.filepool.limit=0 to turn off the
file pooling function. Our understanding is that setting this parameter
only disables file pool and all other functionalities are not affected.
Is it correct? 

                         

                        Tentative Fix:

                        We have modified the soruce code for OpenMQ 4.4
as shown in the attachment file and confirmed the problem is fixed. We'd
appreciate if you could check if our fix is correct. 

                        In RandomAccessStore file, hasMoreElements
method in internal class FileEnumeration determines the value of scanned
by itr and index at the begining. 

                        The value of index is increased in
hasMoreElements method. We think your intention is to set true to
scanned at last when itr is null by executing hasMoreElements and
nextElements repeatedly.  

                        However, as hasMoreElements method is executed
again only when it returned true, scanned remains false in case
hasMoreElements has returned false. 

                        As a result of our investigation, we have added
lines at the end of method which set true to scanned based on itr and
index. This has been modified so that scanned is set as true when false
has been returned. 

                         

                        Regards, 

                        Takuji

                         

                         

                 

         

         

 



[mq-dev] Re: Persistent messages exceeding 1MB are lost

Amy Kang 08/10/2013

[mq-dev] Re: Persistent messages exceeding 1MB are lost

Okubo, Takuji 08/12/2013
Terms of Use; Privacy Policy; Copyright ©2013-2017 (revision 20160708.bf2ac18)
 
 
Close
loading
Please Confirm
Close