1 2 3 Previous Next 32 Replies Latest reply on May 15, 2009 12:18 PM by kconner Go to original post
      • 30. Re: JmsConnectionPool: Allowing control over the number of S
        tfennelly

         

        "Kevin.Conner@jboss.com" wrote:
        For example, someone sets this single parameters to 20 and it works fine with their current listeners. Then they add a new one, opposite type, but forget to 'downgrade' the value.

        Do you not think that having two would make the difference obvious? You could support *both* values without having to force the user into using the lowest one, especially if that lower value happens to be 1.


        I only think it will make it more obvious to the user (from a config perspective) if the user sees the 2 config params in front of him/her when they encounter the issue, or if they've already run into the issue some time before. I also don't think it would be any more obvious to the user than the option of creating another dedicated "one-session-per-connection" provider block and putting the bus configs for those in there in one place.

        "Kevin.Conner@jboss.com" wrote:
        We are trying to minimise impact, as this is a platform branch, so major rewrites are out. But this should be a small change which would have a big impact on usability. Do you not agree?


        I don't disagree, as such ;) I would agree that in theory the change to accomodate this should be straightforward enough, but 2 factors weight against this in my mind... 1) I was under the impression that we were trying to make min changes here and that that would rule out anything that was not absolutely necessary, which I would consider this to be since the user has an "acceptable" (enough IMO) way around it... 2) the current impl is not as straightforward as it should/could be, so making seemingly trivial improvements on top of it would probably just obscure an already obscured chunk of code a little bit more IMO.

        All that said, I think we could debate this until the cows come home, so why don't we say that I just add a second parameter and get on with it :)

        • 31. Re: JmsConnectionPool: Allowing control over the number of S
          tfennelly

          BTW... did you look at the changes in the workspace? Any comments on those?

          • 32. Re: JmsConnectionPool: Allowing control over the number of S
            kconner

             

            "tfennelly" wrote:
            I would consider this to be since the user has an "acceptable" (enough IMO) way around it...


            If you are happy with what you have then go for it, I was just making a suggestion :)

            Kev

            1 2 3 Previous Next