1 2 Previous Next 26 Replies Latest reply on Apr 17, 2009 1:14 PM by Clebert Suconic Go to original post
      • 15. Re: Large messages broken
        Clebert Suconic Master

        I was thinking... I will expose the setOutputStream and setInputStream as some sort of JMS Property, as we already do on expire and other places.

        This way, the user won't need to do any internal casts and it would still work through any JCA provider.

        • 16. Re: Large messages broken
          Clebert Suconic Master

          Right now I' m having eventual failures on MultiThreadFailoverTest and LargeMultiThreadFailloverTests. But I also see those failures without my commits:


          http://hudson.jboss.org/hudson/job/JBM2-tests/4429/testReport/org.jboss.messaging.tests.integration.cluster.failover/XALargeMessageMultiThreadFailoverTest/testC/

          I want to debug a little bit more before commit. I will see if I can find the cause of those failures, and I will talk to you (Tim) over IRC tomorrow before committing it.

          I wouldn' t be able to commit now anyway as SVN at the time I' m writing this post.


          • 17. Re: Large messages broken
            Tim Fox Master

            That test fails very ocassionally on Hudson. As long as you don't increase the frequence of the failure then commit.

            I can run that test in a loop many times and it passes locally.

            Other tests fail more frequently on HUdson, e.g. paging multithread failover test.

            • 18. Re: Large messages broken
              Clebert Suconic Master

              > Other tests fail more frequently on HUdson, e.g. paging multithread failover test.

              I have looked that one.. it is https://jira.jboss.org/jira/browse/JBMESSAGING-1558.


              Right now, the testsuite fails very frequently on failover tests in my box... with or without my changes. But it frequently pass if I run only the failover tests. There is some leak somewhere probably. I suspect (pure guess) about those *FileStorageTest as the failover tests will run after those.


              I will run the failover tests with a big number of iterations to make sure I'm not creating any failures.

              • 19. Re: Large messages broken
                Clebert Suconic Master

                 

                That test fails very ocassionally on Hudson.


                Actually it fails very frequent.

                Set the numIterations=100, and run any of the MultiThreadFailoverTests... You will get hangs and failures.


                That's something to be seen on next week :-)

                • 20. Re: Large messages broken
                  Clebert Suconic Master

                  There are leaks on the testsuite ATM. So far I didn't see anything that would affect production, but failing, stopping & starting servers is leaving some garbage out, what is eventually making it fail.

                  The new code for some reason is making a "bigger user" of those leaks even thought the leaks were already there, already making it fail eventually.RemotingConnection.. etc.

                  So far I have committed my code into a branch.. and I'm trying to cleanup some of those leaks a little bit.

                  I will open another thread later after more investigation with some information about the leaks I have found.

                  This post now is just to inform why I didn't commit the code on the main branch yet.

                  • 21. Re: Large messages broken
                    Tim Fox Master

                    The only failover tests with significant failures are related to large messages and paging, which are both your areas.

                    The other failover tests I can run hundreds of times in a loop without failure.

                    They need to be fixed.

                    • 22. Re: Large messages broken
                      Clebert Suconic Master

                       

                      "timfox" wrote:
                      The only failover tests with significant failures are related to large messages and paging, which are both your areas.

                      The other failover tests I can run hundreds of times in a loop without failure.

                      They need to be fixed.





                      The only reason the other failover tests are not failing is because of the size of the messages.

                      I used to run them (LargeMessage and Paging Failover) hundreds of times also, and some of the recent changes broke them. I will fix them before commit of my changes today.

                      • 23. Re: Large messages broken
                        Clebert Suconic Master

                         

                        "timfox" wrote:
                        ... and paging



                        Paging started failing after one of the refactoring on clustering. We talked about that before and you asked me to look at it after Beta, so I raised a JIRA.

                        • 24. Re: Large messages broken
                          Tim Fox Master

                          I have spent a couple of hours this morning finishing off the LargeMessageExample:

                          1) The explanation in the readme was very poor. The standard of documentation really needs to rise.
                          2) The example didn't output much so it was hard to see if anything was happening
                          3) I limited *both* the client *and* the server to run in 50MB as we discussed previously.
                          4) I changed the message size to 256MB since we are running in a server with 50MB and want the example to run more quickly.
                          5) The header comment in the example was for a different example
                          6) The readme steps did not match the code.
                          7) I added a step to stop and start the server so we can demonstrate the large message survives a restart.

                          Some other questions:

                          a) why the casting to get the input and outputstream - I thought you were going to allow these to be set via a JMS_JBM jms property as we discussed?

                          b) Is setting Input and Ouput streams only allowed on BytesMessage s ? If not, why are you using a BytesMessage.

                          • 25. Re: Large messages broken
                            Clebert Suconic Master

                             

                            "timfox" wrote:

                            Some other questions:

                            a) why the casting to get the input and outputstream - I thoght you were going to allow these to be set via a JMS_JBM jms property as we discussed?

                            b) Is setting Input and Ouput streams only allowed on BytesMessage s ? If not, why are you using a BytesMessage.


                            a)Yes.. I was going to add the JMS Property.. But when I was setting the Property I saw a check for ReadOnly. I could of course overlap the check but I thought it would be deceiving/confusing.... at that minute I then though.. I guess Tim was right and I should just use a cast & method... but if you want the JMS_JBM property back it should be a quick change.

                            b) I think I should enforce it only on Bytes and StreamMessages. This won' t work on TextMessage, ObjectMessage (and maybe others) as I believe the JMS Layer will read the body when the message arrive on those cases.

                            Besides the user could choose to use the readMethods instead of streaming, and getBodyLength was only available on BytesMessage

                            • 26. Re: Large messages broken
                              Clebert Suconic Master

                              as we talked through IRC, I'm placing back the JMS properties:

                              I have created two properties:

                              - JMS_JBM_InputStream - The InputStream
                              - JMS_JBM_OutputStream - The OutputStream


                              And a third one, that I need to find a better name, and decide if I will keep it or not:

                              - JMS_JBM_SaveStream - The OutputStream, but blocking on set


                              With this third property I won't need to do a cast to JBossMessage to wait completion on cases where the user needs to for instance close the connection right after the message was received.


                              If we take out that property, the user will need to do things like:

                              ((JBossMessage)rm).waitCompletionOnStream(10000);


                              As It's done on the LargeMessageExample now.


                              Any thoughts... any idea for a better name on the jms-property?

                              1 2 Previous Next