-
15. Re: JmsConnectionPool: Allowing control over the number of S
We should definitely try to separate the XA/non-XA configuration, as mentioned earlier.
I don't think that the JNDI configuration is the ideal place for this but, given the current architecture, it is probably the best we can do at the moment. The reason I say this is because the value may be different if using different servers (same provider) within the ESB.
The down side of this is, as you say, that the user may inadvertently create multiple pools within a deployment when they had intended to share it.
Kev -
16. Re: JmsConnectionPool: Allowing control over the number of S
"Kevin.Conner@jboss.com" wrote:
We should definitely try to separate the XA/non-XA configuration, as mentioned earlier.
Is this not taken care of by the existence (or not) of "max-sessions-per-connection" in the JNDI config? So, different pools will be created for XA and non-XA configurations and you can control "max-sessions-per-connection" separately for each, no? -
17. Re: JmsConnectionPool: Allowing control over the number of S
"Kevin.Conner@jboss.com" wrote:
The reason I say this is because the value may be different if using different servers (same provider) within the ESB.
Would the different servers not mean different provider URLs and so a different poolKey and so a different pool? -
18. Re: JmsConnectionPool: Allowing control over the number of S
"tfennelly" wrote:
Is this not taken care of by the existence (or not) of "max-sessions-per-connection" in the JNDI config?
If we went down that route then yes, but wasn't that your question? ;)
Kev -
19. Re: JmsConnectionPool: Allowing control over the number of S
"tfennelly" wrote:
Would the different servers not mean different provider URLs and so a different poolKey and so a different pool?
Yes, which is my justification for going down the JNDI route rather than including it in jbossesb-properties.xml. Wasn't jbossesb-properties.xml your other option?
Kev -
20. Re: JmsConnectionPool: Allowing control over the number of S
"Kevin.Conner@jboss.com" wrote:
If we went down that route then yes, but wasn't that your question? ;)
On second thoughts it might add more confusion if done this way as the user would need to consider every deployment and whether it was XA/non XA. It might be easier for the user if we had two separate parameters.
What do you think?
Kev -
21. Re: JmsConnectionPool: Allowing control over the number of S
"Kevin.Conner@jboss.com" wrote:
Yes, which is my justification for going down the JNDI route rather than including it in jbossesb-properties.xml. Wasn't jbossesb-properties.xml your other option?
Ah right... sorry... it was my first suggestion and then I went back towards the JNDI approach after having a closer look at that the JmsConnectionPool container.
So... I think we're saying that if we stick with the JNDI approach (what I currently have) for "max-sessions-per-connection", then we don't need to separate out the XA and non-XA stuff, right? -
22. Re: JmsConnectionPool: Allowing control over the number of S
"Kevin.Conner@jboss.com" wrote:
"Kevin.Conner@jboss.com" wrote:
If we went down that route then yes, but wasn't that your question? ;)
On second thoughts it might add more confusion if done this way as the user would need to consider every deployment and whether it was XA/non XA. It might be easier for the user if we had two separate parameters.
What do you think?
Kev
Not quite sure I follow. Don't they need to be aware of this anyway? -
23. Re: JmsConnectionPool: Allowing control over the number of S
When you saying allow it to be configured centrally in the jbossesb-properties.xml and then override it in the JNDI config?
I think that wuld lead to even more confusion because if someone configures it centrally to something very low, it will result in all pools creating loads of connections (unwittingly). -
24. Re: JmsConnectionPool: Allowing control over the number of S
"tfennelly" wrote:
When you saying allow it to be configured centrally in the jbossesb-properties.xml and then override it in the JNDI config?
Sorry, typo. Should have been "When you saying 'two separate parameters', do you mean allow it to be configured centrally in the jbossesb-properties.xml and then override it in the JNDI config?" -
25. Re: JmsConnectionPool: Allowing control over the number of S
"tfennelly" wrote:
Sorry, typo. Should have been "When you saying 'two separate parameters', do you mean allow it to be configured centrally in the jbossesb-properties.xml and then override it in the JNDI config?"
I hadn't meant that as I had assumed that the default behaviour would be as now, so if the user does not specify it then it works the same.
I was thinking more from the configuration aspect, supporting both an XA and a non-XA version of this parameter within JNDI.
If we choose to do this then the user can set it up once in the jms-provider and the same configuration/pool can be shared between all the associated listeners, whether transactional or not.
If there is only a single JNDI parameter then the user may get into problems if they mix transactional/non-transactional listeners and would have to be aware of the issues.
Kev -
26. Re: JmsConnectionPool: Allowing control over the number of S
"Kevin.Conner@jboss.com" wrote:
"tfennelly" wrote:
Sorry, typo. Should have been "When you saying 'two separate parameters', do you mean allow it to be configured centrally in the jbossesb-properties.xml and then override it in the JNDI config?"
I hadn't meant that as I had assumed that the default behaviour would be as now, so if the user does not specify it then it works the same.
OK, we're fine on that then because the default behavior is as is now."Kevin.Conner@jboss.com" wrote:
I was thinking more from the configuration aspect, supporting both an XA and a non-XA version of this parameter within JNDI.
If we choose to do this then the user can set it up once in the jms-provider and the same configuration/pool can be shared between all the associated listeners, whether transactional or not.
If there is only a single JNDI parameter then the user may get into problems if they mix transactional/non-transactional listeners and would have to be aware of the issues.
Would they get into "problems", or would they simply be eating more connections off the provider than they needed to in the non-XA?
It's just that I think this would complicate and already convoluted implementation a little bit more. Maybe we could save this for the "improved" version of this class, whenever that happens :) -
27. Re: JmsConnectionPool: Allowing control over the number of S
"tfennelly" wrote:
OK, we're fine on that then because the default behavior is as is now.
Grand"tfennelly" wrote:
Would they get into "problems"
Well, if you include runtime failures to obtain sessions because the parameter has been setup for whichever is higher then yes, they would run into "problems"."tfennelly" wrote:
It's just that I think this would complicate and already convoluted implementation a little bit more. Maybe we could save this for the "improved" version of this class, whenever that happens :)
Perhaps we need to see what you have done in that case, as it seems straight forward in the current codebase. Could you move this across to a workspace?
Kev -
28. Re: JmsConnectionPool: Allowing control over the number of S
"Kevin.Conner@jboss.com" wrote:
"tfennelly" wrote:
Would they get into "problems"
Well, if you include runtime failures to obtain sessions because the parameter has been setup for whichever is higher then yes, they would run into "problems".
OK, but that's a config issue as I see it. If you configure it incorrectly, you'll run into problems."Kevin.Conner@jboss.com" wrote:
"tfennelly" wrote:
It's just that I think this would complicate and already convoluted implementation a little bit more. Maybe we could save this for the "improved" version of this class, whenever that happens :)
Perhaps we need to see what you have done in that case, as it seems straight forward in the current codebase. Could you move this across to a workspace?
Sure... here we go: https://svn.jboss.org/repos/labs/labs/jbossesb/workspace/TF_JmsConnectionPool
I'm not suggesting it's not possible to do this, or that there's no merit in it. It's just that I was under the impression we were trying to make the min changes on this rev and since it appears as though any problems associated with this can be configured away, then... -
29. Re: JmsConnectionPool: Allowing control over the number of S
"tfennelly" wrote:
OK, but that's a config issue as I see it. If you configure it incorrectly, you'll run into problems.
Sure, which is why we are discussing easing the configuration for the user.
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."tfennelly" wrote:
Sure... here we go: https://svn.jboss.org/repos/labs/labs/jbossesb/workspace/TF_JmsConnectionPool
Thanks Tom"tfennelly" wrote:
I'm not suggesting it's not possible to do this, or that there's no merit in it. It's just that I was under the impression we were trying to make the min changes on this rev and since it appears as though any problems associated with this can be configured away, then...
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?
Kev