[JBoss JIRA] Created: (JBESB-1733) Remove the use of maxThreads="1" in the gateway declarations of jboss-esb.xml in all quickstarts
by Burr Sutter (JIRA)
Remove the use of maxThreads="1" in the gateway declarations of jboss-esb.xml in all quickstarts
------------------------------------------------------------------------------------------------
Key: JBESB-1733
URL: http://jira.jboss.com/jira/browse/JBESB-1733
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Examples
Affects Versions: 4.2.1 CP2
Reporter: Burr Sutter
Assigned To: Burr Sutter
Fix For: 4.4
maxThreads="99" is presently ignored by the listener which has is-gateway="true"
<jms-listener name="JMS-Gateway"
busidref="quickstartGwChannel"
maxThreads="1"
is-gateway="true"
/>
The fact that this item is in the examples, suggests to people that it can be tuned it up and down but it is in fact, ignored by system. These examples confuse users.
It will now look like the following:
<jms-listener name="JMS-Gateway"
busidref="quickstartGwChannel"
is-gateway="true"
/>
while a native listener will still have max-threads like so:
<jms-listener name="helloWorld"
busidref="quickstartEsbChannel"
maxThreads="1"
/>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 9 months
[JBoss JIRA] Created: (JBESB-467) Reducing registry lookup overhead
by Mark Little (JIRA)
Reducing registry lookup overhead
---------------------------------
Key: JBESB-467
URL: http://jira.jboss.com/jira/browse/JBESB-467
Project: JBoss ESB
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Registry and Repository, Rosetta
Affects Versions: 4.0
Reporter: Mark Little
Assigned To: Kurt Stam
Priority: Critical
Fix For: 4.2, 5.0
>From our previous discussion on reducing registry lookup overhead (currently lookup per message send):
There are a number of solutions to this and we should try to support them all eventually:
(i) EPR lifetime: service deployers can register a lifetime associated with the EPR in the registry and when something reads the EPR it also receives information on how long the EPR will remain valid for. After that time elapses, clients must go back to the registry to get a new copy.
(ii) building on (i), EPRs can be marked as persistent - they never change so one lookup will always be enough.
(iii) interactions with services are scoped by sessions and the EPR is assumed to remain valid for the duration of the session. The service can be marked as useable within such a session.
(iv) EPRs are looked up once per client lifecycle and only rebound if the service fails. If you recall from the original ESB architecture document, service migration is something that is on the roadmap (5.0) and if a service moves it can leave a forwarding address (EPR) and the architecture allows messages to be redirected and eventually short-cut, i.e., the client EPR is updated with the new EPR transparently as a result of receiving a response from a different endpoint.
(iii) and (iv) are really for the 5.0 architecture. However, it should be possible to add something along (i) and (ii) for 4.0. What do you think?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 9 months