[JBoss JIRA] Created: (JBESB-3356) maxThreads does not adequately propagate to HttpClient in HttpRouter, SOAPClient and SOAPProxy
by David Ward (JIRA)
maxThreads does not adequately propagate to HttpClient in HttpRouter, SOAPClient and SOAPProxy
----------------------------------------------------------------------------------------------
Key: JBESB-3356
URL: https://jira.jboss.org/browse/JBESB-3356
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Configuration, Web Services
Affects Versions: 4.8
Reporter: David Ward
Assignee: David Ward
Fix For: 4.9
First, some background:
If one is trying to set the maxThreads for INVM invocation of a Service (where invmScope="GLOBAL"), then one would do it like so:
<service .... invmScope="GLOBAL">
<property name="maxThreads" value="#"/>
....
If one is trying to set the maxThreads for an ESB *aware* Listener's invocation of a Service, then one would do it like so:
<service ...>
<listeners>
<xxx-listener ...>
<property name="maxThreads" value="#"/>
In each of these cases, an action can look for the maxThreads via it's passed in ConfigTree's parent:
config.getParent().getAttribute(ListenerTagNames.MAX_THREADS_TAG).
The HttpRouter takes advantage of this and *defaults* the max-total-connections property it hands to HttpClient to the value of the parent ConfigTree's maxThreads.
Now, the problems:
1) HttpRouter only defaults HttpClient's max-total-connections property to the value of maxThreads. It should also default max-connections-per-host.
2) SOAPClient similarly only defaults HttpClient's max-total-connections property to the value of maxThreads. It should also default max-connections-per-host.
3) The SOAPProxy class "HttpSOAPProxyTransport" wraps HttpRouter, and creates it with a ConfigTree. However, this ConfigTree is a *clone* of the ConfigTree passed into the SOAPProxy, which does *not* have a parent ConfigTree. Thus, there is no parent to get the maxThreads from. Because of that, if someone wants to set the max-total-connections and max-connections-per-host, one has to do this:
<action class="...SOAPProxy" ...>
...
<property name="http-client-properties">
<http-client-property name="max-total-connections" value="#"/>
<http-client-property name="max-connections-per-host" value="#"/>
</property>
or this:
<action class="...SOAPProxy" ...>
...
<property name="file" value="/file-containing-those-props.properties>
In problems 1 and 2, the user needs to know to set the "max-connections-per-host" property. In problem 3, the user needs to know to set both the "max-total-connections" and "max-connections-per-host" properties. If the user doesn't know to do this, they might wonder "why am I getting such bad out-of-the-box performance?"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months
[JBoss JIRA] Created: (JBESB-3309) Aggregator meta data in properties
by Kevin Conner (JIRA)
Aggregator meta data in properties
----------------------------------
Key: JBESB-3309
URL: https://jira.jboss.org/jira/browse/JBESB-3309
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Content Based Routing
Affects Versions: 4.4 CP3
Reporter: Kevin Conner
Fix For: 4.4 CP5
The MessageMulticaster creates an aggregation id and stores this value in message properties. Normally this does not prove to be an issue but when using invm transport it may cause issues.
When the message is sent to multiple services, using pass by reference semantics, then all services will see the *same* properties and may, depending on timing, see the same aggregation id.
The aggregation value should really be in the message context as this section is always duplicated when creating a reference, never shared. The problem we face is that users may already be referencing the property, especially if they are creating a fresh response message, so we need to think about handling this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months
[JBoss JIRA] Created: (JBESB-3289) BpmProcessor documentation anarchy
by Marcel Sebek (JIRA)
BpmProcessor documentation anarchy
----------------------------------
Key: JBESB-3289
URL: https://jira.jboss.org/jira/browse/JBESB-3289
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Documentation
Affects Versions: 4.8
Reporter: Marcel Sebek
The documentation of BpmProcessor is misleading. In the programmers guide, there is the following:
"
The following jBPM commands have been implemented:
- NewProcessInstanceCommand
- StartProcessCommand
- CancelProcessInstanceCommand
- GetProcessInstanceVariablesCommand
"
The correct version is StartProcessInstanceCommand. A few lines bellow,
there is NewProcessInstance-Command (the dash should probably not be
there). Also SignalProcessInstanceCommand is mentioned but that command
has been removed.
Instead of "processdefinition", there should be "process-definition-name".
In ServicesGuide, there is also a note about SignalProcessInstanceCommand and
the "processdefinition" is there too.
There may be more occurrences of these inconsistencies, I've mentioned just the
most obvious.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 10 months