OFBiz
  1. OFBiz
  2. OFBIZ-4794

set different ports for testing in a CI environment (e.g. Jenkins)

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Incomplete
    • Affects Version/s: Release Branch 11.04, SVN trunk, Release Branch 12.04, Release Branch 13.07
    • Fix Version/s: SVN trunk
    • Component/s: framework
    • Labels:
      None

      Description

      In order to run test targets in Jenkins we need to change ports for at least ajp, http and https in test-containers.xml as these ports are most likely to be already in use by the CI server.

      1. OFBIZ-4794 - test port - trunk.patch
        23 kB
        Jacques Le Roux
      2. OFBIZ-4794 - test port - R13.07.patch
        24 kB
        Jacques Le Roux
      3. OFBIZ-4794 - test port - R12.04.patch
        21 kB
        Jacques Le Roux
      4. OFBIZ-4794 - test port - R11.04.patch
        20 kB
        Jacques Le Roux
      5. testSOAPSimpleService.log
        26 kB
        Jacques Le Roux

        Issue Links

          Activity

          Hide
          Pierre Smits added a comment -

          This patch sets the different port numbers for CI testing in test-containers.xml

          Show
          Pierre Smits added a comment - This patch sets the different port numbers for CI testing in test-containers.xml
          Hide
          Jacques Le Roux added a comment -

          Nope, please see my answer on dev ML. Also I recommend to add 1 (not 10000 ) to all ports in test-containers.xml, even those commented out, etc.

          Show
          Jacques Le Roux added a comment - Nope, please see my answer on dev ML . Also I recommend to add 1 (not 10000 ) to all ports in test-containers.xml, even those commented out, etc.
          Hide
          Jacques Le Roux added a comment -

          Done at r1311214

          Show
          Jacques Le Roux added a comment - Done at r1311214
          Hide
          Jacques Le Roux added a comment - - edited

          r1311214 was reverted see http://markmail.org/message/qiocc3lqaywfstvc
          We should see if we can't make it better because of http://svn.apache.org/viewvc?view=revision&revision=1330778

          Show
          Jacques Le Roux added a comment - - edited r1311214 was reverted see http://markmail.org/message/qiocc3lqaywfstvc We should see if we can't make it better because of http://svn.apache.org/viewvc?view=revision&revision=1330778
          Hide
          Jacques Le Roux added a comment -

          Also related to the comment above, I was wondering about ports in serviceengine.xml, I mean

          <service-location name="main-rmi" location="rmi://localhost:1099/RMIDispatcher"/>
          <service-location name="entity-sync-rmi" location="rmi://localhost:1099/RMIDispatcher"/>
          <service-location name="rita-rmi" location="rmi://localhost:1099/RMIDispatcher"/>
          
          Show
          Jacques Le Roux added a comment - Also related to the comment above, I was wondering about ports in serviceengine.xml, I mean <service-location name= "main-rmi" location= "rmi: //localhost:1099/RMIDispatcher" /> <service-location name= "entity-sync-rmi" location= "rmi: //localhost:1099/RMIDispatcher" /> <service-location name= "rita-rmi" location= "rmi: //localhost:1099/RMIDispatcher" />
          Hide
          Jacques Le Roux added a comment -

          OK, our previous tentative failed because we have harcoded ports in serviceengine.xml. But that's only one (small?) part of the problems. When looking for 1099 and 8080 (for instance, more ports numbers have to be considered, 8443, etc.) we get a lot of occurences (23 for 1099, 111 for 8080). Most for 8080 are false results, but still... I will continue on this because this is really a pain to wait for tests to finish on each branch when backporting...

          Show
          Jacques Le Roux added a comment - OK, our previous tentative failed because we have harcoded ports in serviceengine.xml. But that's only one (small?) part of the problems. When looking for 1099 and 8080 (for instance, more ports numbers have to be considered, 8443, etc.) we get a lot of occurences (23 for 1099, 111 for 8080). Most for 8080 are false results, but still... I will continue on this because this is really a pain to wait for tests to finish on each branch when backporting...
          Hide
          Jacques Le Roux added a comment -

          See also INFRA-3590

          Show
          Jacques Le Roux added a comment - See also INFRA-3590
          Hide
          Jacques Le Roux added a comment - - edited

          Also thanks to Jacopo's recent refactoring of ofbiz-component.xml (in base framework component)this will be easier now.

          Show
          Jacques Le Roux added a comment - - edited Also thanks to Jacopo's recent refactoring of ofbiz-component.xml (in base framework component)this will be easier now.
          Hide
          Jacques Le Roux added a comment -

          Attached is a patch, if nobody sees a better way to do this I will commit it. I still have to test 2 tests intance running locally though (will take more than 1 hour I guess...)

          The idea is to use something like

          ant run-tests -Doffsetport=10000
          

          or

          "C:\Program Files\Java\jdk1.6.0_22\bin\java" -Xms128M -Xmx512M -XX:MaxPermSize=512m -jar ofbiz.jar -test -portoffset=10000
          

          This will allow to run the Builbots tests simultaneously on the same VM using ant. The same idea could be used to run the demos, but would need more work (to pass the ofbiz.admin.port value for instance, not a big deal). I will certainly do it as a 1st step of OFBIZ-4763...

          Show
          Jacques Le Roux added a comment - Attached is a patch, if nobody sees a better way to do this I will commit it. I still have to test 2 tests intance running locally though (will take more than 1 hour I guess...) The idea is to use something like ant run-tests -Doffsetport=10000 or "C:\Program Files\Java\jdk1.6.0_22\bin\java" -Xms128M -Xmx512M -XX:MaxPermSize=512m -jar ofbiz.jar -test -portoffset=10000 This will allow to run the Builbots tests simultaneously on the same VM using ant. The same idea could be used to run the demos, but would need more work (to pass the ofbiz.admin.port value for instance, not a big deal). I will certainly do it as a 1st step of OFBIZ-4763 ...
          Hide
          Adrian Crum added a comment -

          It seems to me this is a configuration issue, and usually we solve configuration issues with patches. Why can't the buildbot scripts apply a patch before build/deployment?

          Show
          Adrian Crum added a comment - It seems to me this is a configuration issue, and usually we solve configuration issues with patches. Why can't the buildbot scripts apply a patch before build/deployment?
          Hide
          Jacques Le Roux added a comment -

          It's far easier to use this way, just an ant param. See for instance INFRA-3590 and the buildot ofbiz.conf file (committers only). Same idea for demos, far less burden when we rotate them, idem for tests BTW.

          Show
          Jacques Le Roux added a comment - It's far easier to use this way, just an ant param. See for instance INFRA-3590 and the buildot ofbiz.conf file (committers only) . Same idea for demos, far less burden when we rotate them, idem for tests BTW.
          Hide
          Jacques Le Roux added a comment -

          BTW, I'd like to reopen INFRA-3590, but I have to check the situation before, and if this is really interesting for the project. I guess Erwan is no longer concerned, which is a pity, but well... that's life...

          Show
          Jacques Le Roux added a comment - BTW, I'd like to reopen INFRA-3590 , but I have to check the situation before, and if this is really interesting for the project. I guess Erwan is no longer concerned, which is a pity, but well... that's life...
          Hide
          Scott Gray added a comment -

          +1 for a patch (or patches), command line arguments might work for a while but as configuration differences grow things will be become messy. Easier is not necessarily better.

          Show
          Scott Gray added a comment - +1 for a patch (or patches), command line arguments might work for a while but as configuration differences grow things will be become messy. Easier is not necessarily better.
          Hide
          Jacques Le Roux added a comment -

          Sorry Scott,

          I'm not agains the patches idea, I just don't understand why the other solution would only work for a while.

          Show
          Jacques Le Roux added a comment - Sorry Scott, I'm not agains the patches idea, I just don't understand why the other solution would only work for a while.
          Hide
          Scott Gray added a comment -

          Haven't we made multiple changes in svn to our default configuration in the past to accommodate test and demo deployments? I'm suggesting that those changes and this one could be handled more appropriately by using patches and an ant target to apply them. If there are any more changes in the future (which I'm suggesting won't be easily handled by your approach) they will be easy to make with patches and will avoid over complicating our ant tasks with rarely-used parameter arguments.

          Show
          Scott Gray added a comment - Haven't we made multiple changes in svn to our default configuration in the past to accommodate test and demo deployments? I'm suggesting that those changes and this one could be handled more appropriately by using patches and an ant target to apply them. If there are any more changes in the future (which I'm suggesting won't be easily handled by your approach) they will be easy to make with patches and will avoid over complicating our ant tasks with rarely-used parameter arguments.
          Hide
          Jacques Le Roux added a comment -

          OK I see your point now, though I don't clearly remember specific config changes for test and/or demos. Maybe you are thinking about the work Erwan began on other tools, like Sonar?

          Actually, I like the idea of this unique port offset parameter, because it could be also used any time you want to run 2 (or more) tests instance locally (or any machine), or by and large 2 (or more) OFBiz instances on the same machine without to have to search and apply patches, just pass a parameter, et voilà! This is why I want to also make some small changes for running 2 instances on the same machine, which would be a 1st step for OFBIZ-4763...

          I'm doing a lot of the commits and merges related to contributed work. So you see, this would be a considerable relief in my work, that's why.

          Also I believe having the possibilty to easily change the port number with just a parameter is more flexible. See Olivier Lamy's suggestion about "a random port" on this point

          And, last but not least, I don't foresee much config changes in future and I don't even see how my changes would make them harder.

          Show
          Jacques Le Roux added a comment - OK I see your point now, though I don't clearly remember specific config changes for test and/or demos. Maybe you are thinking about the work Erwan began on other tools, like Sonar? Actually, I like the idea of this unique port offset parameter, because it could be also used any time you want to run 2 (or more) tests instance locally (or any machine), or by and large 2 (or more) OFBiz instances on the same machine without to have to search and apply patches, just pass a parameter, et voilà! This is why I want to also make some small changes for running 2 instances on the same machine, which would be a 1st step for OFBIZ-4763 ... I'm doing a lot of the commits and merges related to contributed work. So you see, this would be a considerable relief in my work, that's why. Also I believe having the possibilty to easily change the port number with just a parameter is more flexible. See Olivier Lamy's suggestion about "a random port" on this point And, last but not least, I don't foresee much config changes in future and I don't even see how my changes would make them harder.
          Hide
          Scott Gray added a comment -

          I can't recall what the changes were, but I recall tweaks over the years.

          I don't think running two or more instances on the same machine is such a common requirement that it should be a command line argument. When such adjustments are needed I don't think it's a big deal to find the configuration and change it, most devs know how to adjust the ports. The adjustment could also be environment specific depending on the app server being deployed with OFBiz (not necessarily embedded). I'm also not suggesting the use of patches as something for developers to be expected to use, I'm only suggesting them specifically for use within the Apache infrastructure. They don't even need to be kept in svn necessarily, the could just as easily reside in someone's apache home folder. That way no changes are needed within the project itself at all. The deployment environments within Apache infra would simply be no different to any other real world deployment.

          I doubt you foresaw this config change either until people started talking about problems with Jenkins so I'm not sure that your argument is valid. I don't see how the port number is any different from any other configuration in OFBiz, they could all arguably be accessible through the command line but where do you draw the line? And how easy will it be for people to adjust these configurations when we support setting them in multiple ways?

          I'm in favor of keeping OFBiz as simple as possible and covering the 90% of use cases while making the remainder easily solvable through normal configuration. I think this crosses a line of making things more complicated for a corner case instead of taking a more standard approach to solving a common deployment problem (the need to adjust the system configuration from their defaults).

          Show
          Scott Gray added a comment - I can't recall what the changes were, but I recall tweaks over the years. I don't think running two or more instances on the same machine is such a common requirement that it should be a command line argument. When such adjustments are needed I don't think it's a big deal to find the configuration and change it, most devs know how to adjust the ports. The adjustment could also be environment specific depending on the app server being deployed with OFBiz (not necessarily embedded). I'm also not suggesting the use of patches as something for developers to be expected to use, I'm only suggesting them specifically for use within the Apache infrastructure. They don't even need to be kept in svn necessarily, the could just as easily reside in someone's apache home folder. That way no changes are needed within the project itself at all. The deployment environments within Apache infra would simply be no different to any other real world deployment. I doubt you foresaw this config change either until people started talking about problems with Jenkins so I'm not sure that your argument is valid. I don't see how the port number is any different from any other configuration in OFBiz, they could all arguably be accessible through the command line but where do you draw the line? And how easy will it be for people to adjust these configurations when we support setting them in multiple ways? I'm in favor of keeping OFBiz as simple as possible and covering the 90% of use cases while making the remainder easily solvable through normal configuration. I think this crosses a line of making things more complicated for a corner case instead of taking a more standard approach to solving a common deployment problem (the need to adjust the system configuration from their defaults).
          Hide
          Jacques Le Roux added a comment -

          I see drawbacks with patches

          • it's not as flexible as a command line parameter when you need to deliver a random port number (see Olivier Lamy's request above for instance)
          • I especially foresee that, again, I will be the one who will handle this for tests and demos (maybe Christian will help, thanks to him). And if it's the case, then I far prefer to use a command line parameter than patches on a committer account (you mean something like https://people.apache.org/~lectran, right?). Else why not, if other persons want to invest in regularly supporting tests and demos, you are warmly welcomed

          >I doubt you foresaw this config change either until people started talking about problems with Jenkins so I'm not sure that your argument is valid.
          Wrong, I foresaw this change long ago. When I worked with Geronimo, were they use a such port offset parameter. I found it a great and flexible idea. You can find it here at least http://markmail.org/message/og7zgvclh64vzlq7, there are other occurences of this idea, just look for http://ofbiz.markmail.org/search/?q=port+offset. The idea is to use a single offset value to changes all ports values in a single shoot. That's where it's different from all others config.

          Anyway, I can agree about providing an ant target to apply ports offset before running an instance (either in demo or test mode). This would be notably easier for instance than changing url.properties value in RequestHandler.getDefaultServerRootUrl()

          So, what's next?

          Show
          Jacques Le Roux added a comment - I see drawbacks with patches it's not as flexible as a command line parameter when you need to deliver a random port number (see Olivier Lamy's request above for instance) I especially foresee that, again, I will be the one who will handle this for tests and demos (maybe Christian will help, thanks to him). And if it's the case, then I far prefer to use a command line parameter than patches on a committer account (you mean something like https://people.apache.org/~lectran , right?). Else why not, if other persons want to invest in regularly supporting tests and demos, you are warmly welcomed >I doubt you foresaw this config change either until people started talking about problems with Jenkins so I'm not sure that your argument is valid. Wrong, I foresaw this change long ago. When I worked with Geronimo, were they use a such port offset parameter. I found it a great and flexible idea. You can find it here at least http://markmail.org/message/og7zgvclh64vzlq7 , there are other occurences of this idea, just look for http://ofbiz.markmail.org/search/?q=port+offset . The idea is to use a single offset value to changes all ports values in a single shoot. That's where it's different from all others config. Anyway, I can agree about providing an ant target to apply ports offset before running an instance (either in demo or test mode). This would be notably easier for instance than changing url.properties value in RequestHandler.getDefaultServerRootUrl() So, what's next?
          Hide
          Jacques Le Roux added a comment -

          BTW we already kinda discussed that in the thread referred by OFBIZ-4763. Though the scope is larger...

          Show
          Jacques Le Roux added a comment - BTW we already kinda discussed that in the thread referred by OFBIZ-4763 . Though the scope is larger...
          Hide
          Scott Gray added a comment -

          Anyway, I can agree about providing an ant target to apply ports offset before running an instance (either in demo or test mode). This would be notably easier for instance than changing url.properties value in RequestHandler.getDefaultServerRootUrl()

          Please don't do that, it wasn't at all what I suggested.

          I give up though, do as you please (as usual).

          Show
          Scott Gray added a comment - Anyway, I can agree about providing an ant target to apply ports offset before running an instance (either in demo or test mode). This would be notably easier for instance than changing url.properties value in RequestHandler.getDefaultServerRootUrl() Please don't do that, it wasn't at all what I suggested. I give up though, do as you please (as usual).
          Hide
          Jacques Le Roux added a comment -

          Not quite sure what you mean by

          1. don't do that
          2. (as usual)

          But sure, I will go my way if nobody is ready to help!

          Show
          Jacques Le Roux added a comment - Not quite sure what you mean by don't do that (as usual) But sure, I will go my way if nobody is ready to help!
          Hide
          Scott Gray added a comment -

          1. I never suggested adding (yet another) ant target specifically for applying port offsets. You said you agree with that suggestion but I never made it. An ant target for applying patches (if one doesn't already exist) is a good idea though.
          2. I meant "as usual" in that it is all too common for a committer to be given advice (from more than one reviewer) and then choose to ignore it. Also, suggesting you'll go against recommendations because no one is willing to help is ridiculous, it's basically trying to blackmail people into doing your work for you

          Show
          Scott Gray added a comment - 1. I never suggested adding (yet another) ant target specifically for applying port offsets. You said you agree with that suggestion but I never made it. An ant target for applying patches (if one doesn't already exist) is a good idea though. 2. I meant "as usual" in that it is all too common for a committer to be given advice (from more than one reviewer) and then choose to ignore it. Also, suggesting you'll go against recommendations because no one is willing to help is ridiculous, it's basically trying to blackmail people into doing your work for you
          Hide
          Jacques Le Roux added a comment - - edited

          === FORGOT A 4th point ===

          1. Ha sorry indeed, I did not mean port offset in this way. I meant the way you suggested of course (would not make sense anyway, what would be a port offset patch?). Something like
            Index: ofbiz-component.xml
            ===================================================================
            --- ofbiz-component.xml	(revision 1493331)
            +++ ofbiz-component.xml	(working copy)
            @@ -34,7 +34,7 @@
                 <!-- load the naming (JNDI) server -->
                 <container name="naming-container" loaders="rmi" class="org.ofbiz.base.container.NamingServiceContainer">
                     <property name="host" value="0.0.0.0"/>
            -        <property name="port" value="1099"/>
            +        <property name="port" value="21099"/>
                 </container>
             
                 <!-- load BeanShell remote telnet server -->
            
          2. Work for me? You must be kidding!

          Anyway, thanks for you comments Adrian and Scott. But I will do as I want mostly because:

          1. I don't like much the complicated idea of maintaining patches in one committers people folder, or any places anyway
          2. I know I'm the one who will eventually have to support it
          3. I'm not convinced that the patch I proposed will be annoying for anybody and I don't foresee much config changes again in the future
          4. This will allow to see what we can do for the Sonar Infra task pending, where they want a possible random port setting
          Show
          Jacques Le Roux added a comment - - edited === FORGOT A 4th point === Ha sorry indeed, I did not mean port offset in this way. I meant the way you suggested of course (would not make sense anyway, what would be a port offset patch?). Something like Index: ofbiz-component.xml =================================================================== --- ofbiz-component.xml (revision 1493331) +++ ofbiz-component.xml (working copy) @@ -34,7 +34,7 @@ <!-- load the naming (JNDI) server --> <container name= "naming-container" loaders= "rmi" class= "org.ofbiz.base.container.NamingServiceContainer" > <property name= "host" value= "0.0.0.0" /> - <property name= "port" value= "1099" /> + <property name= "port" value= "21099" /> </container> <!-- load BeanShell remote telnet server --> Work for me? You must be kidding! Anyway, thanks for you comments Adrian and Scott. But I will do as I want mostly because: I don't like much the complicated idea of maintaining patches in one committers people folder, or any places anyway I know I'm the one who will eventually have to support it I'm not convinced that the patch I proposed will be annoying for anybody and I don't foresee much config changes again in the future This will allow to see what we can do for the Sonar Infra task pending, where they want a possible random port setting
          Hide
          Adrian Crum added a comment -

          "I don't like much the complicated idea of maintaining patches in one committers people folder, or any places anyway
          I know I'm the one who will eventually have to support it"

          That has to be the most short-sighted, selfish comment I've seen from Jacques.

          Jacques - if you go ahead with your plans, it will be the rest of us who have to maintain and support your overly-complicated convenience. Please don't do this.

          Show
          Adrian Crum added a comment - "I don't like much the complicated idea of maintaining patches in one committers people folder, or any places anyway I know I'm the one who will eventually have to support it" That has to be the most short-sighted, selfish comment I've seen from Jacques. Jacques - if you go ahead with your plans, it will be the rest of us who have to maintain and support your overly-complicated convenience. Please don't do this.
          Hide
          Jacques Le Roux added a comment -

          In what is my plan short-sighted, selfish and overly-complicated? Please explain!

          Show
          Jacques Le Roux added a comment - In what is my plan short-sighted, selfish and overly-complicated? Please explain!
          Hide
          Jacques Le Roux added a comment -

          A last thing, for this to be interesting for Buildbot tests I will need to backport it to releases...

          Show
          Jacques Le Roux added a comment - A last thing, for this to be interesting for Buildbot tests I will need to backport it to releases...
          Hide
          Jacques Le Roux added a comment -

          Anyway, if we would have used patches, the same (changes in releases) would have be needed:

          • specific patches for releases (ports numbers must be different, because we want to run any of them simultaneously, also with trunk)
          • either with
            • ant targets (easier for infra but needs backports)
            • or calls from the Builbot scripts (no backports but more work for infra, I guess not wanted)
          Show
          Jacques Le Roux added a comment - Anyway, if we would have used patches, the same (changes in releases) would have be needed: specific patches for releases (ports numbers must be different, because we want to run any of them simultaneously, also with trunk) either with ant targets (easier for infra but needs backports) or calls from the Builbot scripts (no backports but more work for infra, I guess not wanted)
          Hide
          sirdouglascook@hotmail.com added a comment -

          PLEASE PLEASE PLEASE TAKE ME OFF OF YOUR MAILING LIST !!!

          I subscribed too and unsubscribed from OFBIZ as I would love to have this product; however,
          it isn't as user friendly as Mengenta. I have Mengenta (sorry about spelling) and I had a store selling in
          one day... after a week I gave up on OFBIZ. Maybe ten years from now they will be the top application on
          Ubuntu... I can see that... However, your just not going to grow (collect programmers) if you not collecting users.
          IMHO

          That said, add a link to the UNsubscribe pages so that it will be easier for others to UNsubscribe to JIRA.. thanks

          Lastly, please remember to search your email lists/databases and remove sirdouglascook@hotmail.com

          PLEASE PLEASE PLEASE TAKE ME OFF OF YOUR MAILING LIST !!!

          Best regards,

          Douglas Cook

          P.S. I am really disappointed as OFBIZ is going to be the most awesome application "ever" when
          it so easy that windows users can install and use it. Secondly, If OFBIZ doesn't install like other
          applications in UBUNTU.. please remove it... as your just generating bad publicity. Which will be
          another hurdle to overcome when OFBIZ becomes user friendly and complete. IMHO

          Show
          sirdouglascook@hotmail.com added a comment - PLEASE PLEASE PLEASE TAKE ME OFF OF YOUR MAILING LIST !!! I subscribed too and unsubscribed from OFBIZ as I would love to have this product; however, it isn't as user friendly as Mengenta. I have Mengenta (sorry about spelling) and I had a store selling in one day... after a week I gave up on OFBIZ. Maybe ten years from now they will be the top application on Ubuntu... I can see that... However, your just not going to grow (collect programmers) if you not collecting users. IMHO That said, add a link to the UNsubscribe pages so that it will be easier for others to UNsubscribe to JIRA.. thanks Lastly, please remember to search your email lists/databases and remove sirdouglascook@hotmail.com PLEASE PLEASE PLEASE TAKE ME OFF OF YOUR MAILING LIST !!! Best regards, Douglas Cook P.S. I am really disappointed as OFBIZ is going to be the most awesome application "ever" when it so easy that windows users can install and use it. Secondly, If OFBIZ doesn't install like other applications in UBUNTU.. please remove it... as your just generating bad publicity. Which will be another hurdle to overcome when OFBIZ becomes user friendly and complete. IMHO
          Hide
          Jacques Le Roux added a comment -

          I want to backport this to releases to facilitate things on Buildbot. Else it has much less interest. I will attach the patches for each.

          Show
          Jacques Le Roux added a comment - I want to backport this to releases to facilitate things on Buildbot. Else it has much less interest. I will attach the patches for each.
          Hide
          Jacques Le Roux added a comment -

          I have removed the patches. There were 2 issues, I have fixed one, resolving the other

          Show
          Jacques Le Roux added a comment - I have removed the patches. There were 2 issues, I have fixed one, resolving the other
          Hide
          Jacques Le Roux added a comment -

          After unsuccesfully trying to understand why I get a Transaction Timeout error with testSOAPSimpleService when running trunk tests with concurrently one release instance tests, I decided to attach the patch again.

          I did not get this error when I run 2 releases instances tests (R11.04 and R12.04) but maybe R13.07 with another one. Since R13.07 is not much different than trunk I guess I will get the same error, which is quite obvcure to me. I can't relate to my changes though it must be related.

          If someone could also test it and have a look it would be great.

          Show
          Jacques Le Roux added a comment - After unsuccesfully trying to understand why I get a Transaction Timeout error with testSOAPSimpleService when running trunk tests with concurrently one release instance tests, I decided to attach the patch again. I did not get this error when I run 2 releases instances tests (R11.04 and R12.04) but maybe R13.07 with another one. Since R13.07 is not much different than trunk I guess I will get the same error, which is quite obvcure to me. I can't relate to my changes though it must be related. If someone could also test it and have a look it would be great.
          Hide
          Jacques Le Roux added a comment -

          Actually I was wrong. Running R12.04 and R13.07 tests simultaneously I get the same Transaction Timeout error for SOAPSimpleService on both sides.
          I certainly ran 12.04 with 11.04, and maybe because 11.04 tests are far less numerous I did not cross this issue.

          Show
          Jacques Le Roux added a comment - Actually I was wrong. Running R12.04 and R13.07 tests simultaneously I get the same Transaction Timeout error for SOAPSimpleService on both sides. I certainly ran 12.04 with 11.04, and maybe because 11.04 tests are far less numerous I did not cross this issue.
          Hide
          Jacques Le Roux added a comment -

          I think, at this stage, attaching 4 patches was not enough. I need to explain what I did. It's finally few small changes. I put much care in them and made a lot of testing.

          What's for?
          OOTB the port offset is interesting in at least 3 cases:

          1. To simultaneously run tests on the same Buildbot machine. This is related to this thread
          2. To simultaneously run the demos without having to change much things, just one parameter
          3. To eventually run Sonar on OFBiz sources INFRA-3590 (I will reopen it when all will be OK)

          How it's done?
          Basically, I just added a portoffset integer parameter to some ant targets (of course this JVM param can also be used in a Java call from command line):

          • in trunk and R13.07: start, start-batch, start-debug, start-pos, start-both, run-tests and run-test
          • in R12.04 and R11.04: run-tests, run-test. I did not set start targets because anyway it would miss the admin port offset, withouh much changes. So can't be used to demonstrate. We will continue to use the current paches for those.

          The portoffset parameter is set to zero by default in ClassLoaderContainer.java.
          If a value is passed, it's then grabed by Config.java and passed to ClassLoaderContainer.java, where it's set to this value.

          The portoffset is then used to change in one shoot all the default ports values defined (in config or hardcoded), and the admin port value in R13.07 and trunk.
          This is done in following classes:
          CatalinaContainer
          NamingServiceContainer
          ServiceEngine through ServiceLocation
          RmiServiceContainer
          XMLRPCClientEngine
          XmlRpcTests

          To avoid hardcoding locations in services definitions, I also had to create some service-locations: main-local-soap and main-remote-soap

          What are the constraints?

          • For demos: the offset should not be applied to trunk because <service-location name="main-remote-soap" location="http://demo-trunk.ofbiz.apache.org:8080/webtools/control/SOAPService"/> is used for tests by trunk and all releases. It's useless to apply to trunk anyway, offsetting port in releases is enough.
          • I did not take into account the Ideal payment harcoded port values in IdealPaymentServiceTest.java. Weirdly I did not cross error during tests, though it seems there are tests using an harcoded port in url.

          What is the status?
          Locally (on Win XP) I ran many tests combinations with <<ant load-demo run-tests>>.
          Applying the portoffset on a sole running test instance has no effects. I have still some fails (no errors) but those are not related to my changes, they appear also without.
          But when I run a combination of any releases/trunk but with R11.04, I get a time out error with testSOAPSimpleService, that I can't explain so far.
          If I run the trunk alone with the portoffset no errors occur. Same if I run a release with portoffset and only testSOAPSimpleService in trunk (w/ or w/o portoffset)

          To summarize: these changes will be used to run Buildot tests instances simultaneously . And, for coming releases, to run demos without having to create patches. Simply running ant start with a portoffset value which will take care of all ports values, including admin port. For running R12.04 demo as stable we will still need to create a patch for the last time.

          What I will to do for now: commit the patches and test if I cross the same issue on Buildbot. If it's the same (99% chances it will) I will revert and will continue to locally try to find the reason . I believe this issue is unrelated to the changes I implemened. And it's just because it's now possible to simultaneously run tests that it appears.

          BTW I just noticed that when you run R11.04 with R12.04, R12.04 takes almost all the CPU (XP is not very, while when running any combinations w/o R11.04 the CPU load is shared.
          Also there are far less tests in R11.04, which coul be the reason when I run it with another test run instance there are no issues. Because R11.04 tests finish before the other instance gets to run testSOAPSimpleService.

          Show
          Jacques Le Roux added a comment - I think, at this stage, attaching 4 patches was not enough. I need to explain what I did. It's finally few small changes. I put much care in them and made a lot of testing. What's for? OOTB the port offset is interesting in at least 3 cases: To simultaneously run tests on the same Buildbot machine. This is related to this thread To simultaneously run the demos without having to change much things, just one parameter To eventually run Sonar on OFBiz sources INFRA-3590 (I will reopen it when all will be OK) How it's done? Basically, I just added a portoffset integer parameter to some ant targets (of course this JVM param can also be used in a Java call from command line): in trunk and R13.07: start, start-batch, start-debug, start-pos, start-both, run-tests and run-test in R12.04 and R11.04: run-tests, run-test. I did not set start targets because anyway it would miss the admin port offset, withouh much changes. So can't be used to demonstrate. We will continue to use the current paches for those. The portoffset parameter is set to zero by default in ClassLoaderContainer.java. If a value is passed, it's then grabed by Config.java and passed to ClassLoaderContainer.java, where it's set to this value. The portoffset is then used to change in one shoot all the default ports values defined (in config or hardcoded), and the admin port value in R13.07 and trunk. This is done in following classes: CatalinaContainer NamingServiceContainer ServiceEngine through ServiceLocation RmiServiceContainer XMLRPCClientEngine XmlRpcTests To avoid hardcoding locations in services definitions, I also had to create some service-locations: main-local-soap and main-remote-soap What are the constraints? For demos: the offset should not be applied to trunk because <service-location name="main-remote-soap" location="http://demo-trunk.ofbiz.apache.org:8080/webtools/control/SOAPService"/> is used for tests by trunk and all releases . It's useless to apply to trunk anyway, offsetting port in releases is enough. I did not take into account the Ideal payment harcoded port values in IdealPaymentServiceTest.java. Weirdly I did not cross error during tests, though it seems there are tests using an harcoded port in url. What is the status? Locally (on Win XP) I ran many tests combinations with <<ant load-demo run-tests>>. Applying the portoffset on a sole running test instance has no effects. I have still some fails (no errors) but those are not related to my changes, they appear also without. But when I run a combination of any releases/trunk but with R11.04, I get a time out error with testSOAPSimpleService, that I can't explain so far. If I run the trunk alone with the portoffset no errors occur. Same if I run a release with portoffset and only testSOAPSimpleService in trunk (w/ or w/o portoffset) To summarize: these changes will be used to run Buildot tests instances simultaneously . And, for coming releases, to run demos without having to create patches. Simply running ant start with a portoffset value which will take care of all ports values, including admin port. For running R12.04 demo as stable we will still need to create a patch for the last time. What I will to do for now: commit the patches and test if I cross the same issue on Buildbot. If it's the same (99% chances it will) I will revert and will continue to locally try to find the reason . I believe this issue is unrelated to the changes I implemened. And it's just because it's now possible to simultaneously run tests that it appears. BTW I just noticed that when you run R11.04 with R12.04, R12.04 takes almost all the CPU (XP is not very, while when running any combinations w/o R11.04 the CPU load is shared. Also there are far less tests in R11.04, which coul be the reason when I run it with another test run instance there are no issues. Because R11.04 tests finish before the other instance gets to run testSOAPSimpleService.
          Hide
          Jacques Le Roux added a comment -

          BTW, this is what I get in log for the testSOAPSimpleService error

          Show
          Jacques Le Roux added a comment - BTW, this is what I get in log for the testSOAPSimpleService error
          Hide
          Jacques Le Roux added a comment -

          I commited all concerned releases and trunk. But I juts realise that R11.04 tests failed last time seems related to ofbizssl.jks missing. I did not reproduce that locally so hopefully it's OK.

          Show
          Jacques Le Roux added a comment - I commited all concerned releases and trunk. But I juts realise that R11.04 tests failed last time seems related to ofbizssl.jks missing. I did not reproduce that locally so hopefully it's OK.
          Hide
          Jacques Le Roux added a comment - - edited

          == TAKE OFBIZ-5329 INTO ACCOUNT ==
          I completed previous commits because of INFRA-6790, so we have

          trunk at revisions: 1525909 + 1526533 + 1526560
          R13.07 at revisions: 1525910 + 1526534 + 1526561
          R12.04 at revisions: 1525906 + 1526535
          R11.04 at revisions: 1525907 + 1526536

          Show
          Jacques Le Roux added a comment - - edited == TAKE OFBIZ-5329 INTO ACCOUNT == I completed previous commits because of INFRA-6790 , so we have trunk at revisions: 1525909 + 1526533 + 1526560 R13.07 at revisions: 1525910 + 1526534 + 1526561 R12.04 at revisions: 1525906 + 1526535 R11.04 at revisions: 1525907 + 1526536
          Hide
          Jacques Le Roux added a comment -

          OK the same testSOAPSimpleService fails for trunk and R13.07 (R12.04 and R11.04 have only fails no errors). I will revert and continue locally...

          Show
          Jacques Le Roux added a comment - OK the same testSOAPSimpleService fails for trunk and R13.07 (R12.04 and R11.04 have only fails no errors). I will revert and continue locally...
          Hide
          Jacques Le Roux added a comment -

          Reverted trunk at revision: 1526583

          Show
          Jacques Le Roux added a comment - Reverted trunk at revision: 1526583
          Hide
          Jacques Le Roux added a comment -

          Reverted from R13.07 at revision: 1526596

          Show
          Jacques Le Roux added a comment - Reverted from R13.07 at revision: 1526596
          Hide
          Jacques Le Roux added a comment -

          Reverted from R12.04 at revision 1526621

          Note to myself: a non functional change to ReportScreens.xml had slipped in at r1525906. It should not be carried in next time...

          Show
          Jacques Le Roux added a comment - Reverted from R12.04 at revision 1526621 Note to myself: a non functional change to ReportScreens.xml had slipped in at r1525906. It should not be carried in next time...
          Hide
          Jacques Le Roux added a comment -

          Reverted from R11.04 at revision 1526645

          Show
          Jacques Le Roux added a comment - Reverted from R11.04 at revision 1526645
          Hide
          Jacques Le Roux added a comment -

          Actually this testSOAPSimpleService error and the fails are not related to my changes. When you run tests on R12.04 AND SIMULTANEOUSLY R13.07 by changing the 8080, 8443 and 1099 ports on each instance you reproduce the same.

          So my desire to run many test instances on Builbot is impeded. It's more complicated than I thought

          Show
          Jacques Le Roux added a comment - Actually this testSOAPSimpleService error and the fails are not related to my changes. When you run tests on R12.04 AND SIMULTANEOUSLY R13.07 by changing the 8080, 8443 and 1099 ports on each instance you reproduce the same. So my desire to run many test instances on Builbot is impeded. It's more complicated than I thought
          Hide
          Jacques Le Roux added a comment - - edited

          I gave up on running simultaneous buids. It could not work in a reasonable, time and I found a simpler solution for Buildbot (I used the Buildbot interlock feature).

          I have commited a set of changes in trunk at revision: 1533839. Its goal is twofold:

          1. To eventually run Sonar on OFBiz sources INFRA-3590
          2. To simultaneously run the demos without having to change much things each time we deploy new releases, just one parameter (this will need to have the same commited in R13.07... to be discussed...)
          Show
          Jacques Le Roux added a comment - - edited I gave up on running simultaneous buids. It could not work in a reasonable, time and I found a simpler solution for Buildbot (I used the Buildbot interlock feature). I have commited a set of changes in trunk at revision: 1533839. Its goal is twofold: To eventually run Sonar on OFBiz sources INFRA-3590 To simultaneously run the demos without having to change much things each time we deploy new releases, just one parameter (this will need to have the same commited in R13.07... to be discussed...)
          Hide
          Jacques Le Roux added a comment -

          Backported in R13.07 at r1547186, nothing else to do here now, closing

          Show
          Jacques Le Roux added a comment - Backported in R13.07 at r1547186, nothing else to do here now, closing
          Hide
          Jacques Le Roux added a comment -

          I have added a change for url.properties and WebSite entity in
          trunk r1549015
          R13.07 r1549016+1549019

          Show
          Jacques Le Roux added a comment - I have added a change for url.properties and WebSite entity in trunk r1549015 R13.07 r1549016+1549019
          Hide
          Jacques Le Roux added a comment -

          At r1553962+1553962 I have committed a small change to allow to use the portoffset paramter with the run-tests target, this is for OFBiz-Sonar: INFRA-3590

          Show
          Jacques Le Roux added a comment - At r1553962+1553962 I have committed a small change to allow to use the portoffset paramter with the run-tests target, this is for OFBiz-Sonar: INFRA-3590

            People

            • Assignee:
              Jacques Le Roux
              Reporter:
              Pierre Smits
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 1h
                1h
                Remaining:
                Remaining Estimate - 1h
                1h
                Logged:
                Time Spent - Not Specified
                Not Specified

                  Development