Re: load balancing?
On 7/26/07, cui.hailin [EMAIL PROTECTED] wrote: in Apache ServiceMix Home Documentation Guides Clustering Please see my responses inline below: 1,load balancing of messages across servers/machines ? Multiple JMS consumers can be pointed at a single queue and compete for the consumption of messages providing load balancing functionality. This can allow multiple servicemix-jms consumers to compete for messages, sending them into flows through identical groups of components deployed on separate instances of ServiceMix. ServiceMix also provides the ability to create your own EndpointResolver and/or EndpointChooser. The EndpointResolver employs the strategy pattern for plugging in custom policies for resolving endpoints and uses an EndpointChooser to provide the actual endpoint selection policy. See the Javadocs for info: http://incubator.apache.org/servicemix/dist/servicemix-3.1-incubating/site/core/servicemix-core/apidocs/org/apache/servicemix/jbi/resolver/EndpointResolver.html http://incubator.apache.org/servicemix/dist/servicemix-3.1-incubating/site/core/servicemix-core/apidocs/org/apache/servicemix/jbi/resolver/EndpointChooser.html 2,high availability (HA) of services and fault tolerance (if a machine crashes, messages are automatically redelivered to another machine HA is provided by configuring ActiveMQ for this purpose. ServiceMix is built on top of the ActiveMQ message broker so all of the ActiveMQ HA features are available within ServiceMix. Most typically this involves configuring a network of brokers in a master/slave configuration. See the ActiveMQ docs for more info on this. 3,durability (persist messages to disk/database) to ensure they survive catastrophic hardware failure Again, this feature is provided by way of the ActiveMQ message broker and it's implementation of the JMS 1.1 spec. Persistent messaging is configured in ActiveMQ by default and is easy to reconfigure in a custom manner. BTW, this message should be on the servicemix-users list, so I'm CC'ing that list. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://activemq.org/ Apache ServiceMix - http://servicemix.org/ Castor - http://castor.org/
Re: load balancing?
JMSFlow do not implement the feature. -- View this message in context: http://www.nabble.com/load-balancing--tf4151781s12049.html#a11811898 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
load balancing?
in Apache ServiceMix Home Documentation Guides Clustering 1,load balancing of messages across servers/machines ? 2,high availability (HA) of services and fault tolerance (if a machine crashes, messages are automatically redelivered to another machine 3,durability (persist messages to disk/database) to ensure they survive catastrophic hardware failure how to do? -- View this message in context: http://www.nabble.com/load-balancing--tf4151781s12049.html#a11810961 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
[jira] Closed: (GERONIMO-2677) HttpSession Relocation - Sticky load-balancing via HTTP Cookie
[ https://issues.apache.org/jira/browse/GERONIMO-2677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-2677. --- Resolution: Fixed Fix Version/s: 2.0-M2 Sticky load-balancing is now working fine. HttpSession Relocation - Sticky load-balancing via HTTP Cookie -- Key: GERONIMO-2677 URL: https://issues.apache.org/jira/browse/GERONIMO-2677 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Clustering Reporter: Gianny Damour Assigned To: Gianny Damour Fix For: 2.0-M2 Attachments: GERONIMO-2677.patch, JETTY-2677.patch When an HttpSession is migrated from one node to another: * its id must be updated (the worker name suffix is to be set to the name of the node owning the HttpSession); and * the session cookie must be updated accordingly. The worker name suffix, which can be retrieved from the session cookie, can be leverage to configure sticky load-balancing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2677) HttpSession Relocation - Sticky load-balancing via HTTP Cookie
HttpSession Relocation - Sticky load-balancing via HTTP Cookie -- Key: GERONIMO-2677 URL: http://issues.apache.org/jira/browse/GERONIMO-2677 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: Clustering Reporter: Gianny Damour Assigned To: Gianny Damour When an HttpSession is migrated from one node to another: * its id must be updated (the worker name suffix is to be set to the name of the node owning the HttpSession); and * the session cookie must be updated accordingly. The worker name suffix, which can be retrieved from the session cookie, can be leverage to configure sticky load-balancing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2677) HttpSession Relocation - Sticky load-balancing via HTTP Cookie
[ http://issues.apache.org/jira/browse/GERONIMO-2677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour updated GERONIMO-2677: Attachment: GERONIMO-2677.patch JETTY-2677.patch HttpSession Relocation - Sticky load-balancing via HTTP Cookie -- Key: GERONIMO-2677 URL: http://issues.apache.org/jira/browse/GERONIMO-2677 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Clustering Reporter: Gianny Damour Assigned To: Gianny Damour Attachments: GERONIMO-2677.patch, JETTY-2677.patch When an HttpSession is migrated from one node to another: * its id must be updated (the worker name suffix is to be set to the name of the node owning the HttpSession); and * the session cookie must be updated accordingly. The worker name suffix, which can be retrieved from the session cookie, can be leverage to configure sticky load-balancing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2677) HttpSession Relocation - Sticky load-balancing via HTTP Cookie
[ http://issues.apache.org/jira/browse/GERONIMO-2677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461613 ] Gianny Damour commented on GERONIMO-2677: - I attach two patches: * JETTY-2677.patch: Jetty6 patch in order to simplify the integration code. ** AbstractSessionManager.Session is updated such that its two constructors share the same logic with respect to the definition of the _id field. Also, the method initValues is added such that sub-classes can explicitly control the initialization of the _values field. ** SessionHandler.handle is refactored: the method setRequestedId has been extracted such that sub-classes can also share this behavior; and ** Request.getSession(boolean) is improved such that a session cookie is set against a session whose id has changed (following a migration). * GERONIMO-2677.patch: Geronimo patch to leverage the Jetty6 code base after having applied the Jetty6 patch. HttpSession Relocation - Sticky load-balancing via HTTP Cookie -- Key: GERONIMO-2677 URL: http://issues.apache.org/jira/browse/GERONIMO-2677 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Clustering Reporter: Gianny Damour Assigned To: Gianny Damour Attachments: GERONIMO-2677.patch, JETTY-2677.patch When an HttpSession is migrated from one node to another: * its id must be updated (the worker name suffix is to be set to the name of the node owning the HttpSession); and * the session cookie must be updated accordingly. The worker name suffix, which can be retrieved from the session cookie, can be leverage to configure sticky load-balancing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-468) Queue load balancing - optionally give highest priority to the local connection, then local broker then networks
[ https://issues.apache.org/activemq/browse/AMQ-468?page=all ] Hiram Chirino updated AMQ-468: -- Fix Version/s: 4.2 (was: 4.1.0) Queue load balancing - optionally give highest priority to the local connection, then local broker then networks Key: AMQ-468 URL: https://issues.apache.org/activemq/browse/AMQ-468 Project: ActiveMQ Issue Type: Improvement Reporter: Rob Davies Fix For: 4.2.0 For Queues, as an option assign the highest priority for dispatching to the local connection, then the local broker, then the cluster etc. Right now we favour consumers on the local broker above consumers on remote brokers. However we should prioritise consumers on the same session, connection or VM transport above consumers in other processes etc -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-816) new transport for load balancing client requests across many brokers
[ https://issues.apache.org/activemq/browse/AMQ-816?page=comments#action_36940 ] james strachan commented on AMQ-816: We currently have the fanount transport which does most of this - the main thing to add is the ability to choose the broker to send a command to depending on the context. e.g. when using a transaction, choose a broker and use it for the entire transaction (unless the broker dies). When sending a MessageAck use the broker that sent the original message etc. new transport for load balancing client requests across many brokers Key: AMQ-816 URL: https://issues.apache.org/activemq/browse/AMQ-816 Project: ActiveMQ Issue Type: Improvement Reporter: james strachan Fix For: 4.2 Rather than creating store and forward networks, it might be nice to have a kind of composite transport where... * consumers are created on each broker found/discovered. This allows messages to be sent to any broker and consumed by any consumer * producers could dynmically choose which broker to send a message to (or could just pick one broker per session/producer) this allows for a load balancing layer at the client side which avoids the need for store/forward networks (which results in more network traffic and often increases load on the brokers). So it basically pushes load back to the clients. The downside of this appoach is that the clients have more connections to brokers - but given the linear scalability of this, it sounds a great idea to me at least :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-816) new transport for load balancing client requests across many brokers
[ https://issues.apache.org/activemq/browse/AMQ-816?page=comments#action_36560 ] Hiram Chirino commented on AMQ-816: --- Sounds similar to the fanout transport we currently have. Except that in the fanout transport it's backwards. We broadcast the publish to multiple brokers and only consume from 1. new transport for load balancing client requests across many brokers Key: AMQ-816 URL: https://issues.apache.org/activemq/browse/AMQ-816 Project: ActiveMQ Type: Improvement Reporter: james strachan Fix For: 4.2 Rather than creating store and forward networks, it might be nice to have a kind of composite transport where... * consumers are created on each broker found/discovered. This allows messages to be sent to any broker and consumed by any consumer * producers could dynmically choose which broker to send a message to (or could just pick one broker per session/producer) this allows for a load balancing layer at the client side which avoids the need for store/forward networks (which results in more network traffic and often increases load on the brokers). So it basically pushes load back to the clients. The downside of this appoach is that the clients have more connections to brokers - but given the linear scalability of this, it sounds a great idea to me at least :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-762) Message Group based load balancing not well distributed across brokers
[ https://issues.apache.org/activemq/browse/AMQ-762?page=comments#action_36536 ] Sunil Bosco Rodrigues commented on AMQ-762: --- Using spring 2.0 and Active MQ 4.0 I had the original problem reported by Craig. INFO Service - Sync error occurred: javax.jms.InvalidClientIDException: Broker: localhost - Client: ID:inspiron-1410-114619274 7453-2:1 already connected I could get this to work by replacing the DefaultMessageListenerFactory with the SimpleMessageListenerFactory class and I did not have this problem. It's a workaround so hope it helps resolving the original issue. Thanks, Rodrigues. Message Group based load balancing not well distributed across brokers -- Key: AMQ-762 URL: https://issues.apache.org/activemq/browse/AMQ-762 Project: ActiveMQ Type: Bug Versions: 4.0 Environment: Active MQ 4.0, Lingo 1.1 Reporter: Sanjiv Jivan Attachments: lingocluster.zip I started 2 servers, each of which have an embedded broker. A shell based chield sends messages to 30 different message groups (using command register message group in the samepl app provided. Only 2 mesages are received by server1, 3 by server2 and 25 by server3. The load balancing distribution is highly unenen. As suggested, I also tried setting a low destination queue prefetch value (consumer.prefetch=1) but the result was the same. To run sample : 1. Unzip attached file and run maven.bat from the oot directory (Maven 1.0) 2. Open 3 DOS boxes in the dist\bin folder and run startoptimizerPooled.bat, startOptimizerPooled2.bat and startOptimizerPooled3.bat in each DOS box respectively. 3. Step 2 starts a network of 3 servers apps which have an embedded broker. The Spring configuration files for each of these servers is in the dist\conf directory. 4. Open another DOS box in dist\bin and start a test client by running startClientShell.bat 5. This command driver test client accepts commads in the form register message group close message group and exit NOTE: The command close message group is supposed to close/reset the message group by issueing a JMSXGroupSeq header as described here : http://www.activemq.org/site/message-groups.html 6. Try sending several messages to the server by issuing several commands like regeister A, register B, register C and so on.. You'll see the highly uneven distibution of messages. Only one or two messages are received my 2 servers while the third one receives a majority of the messages. Please let me know if you have trouble running the sample or replicating the issue. Thanks, Sanjiv -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-468) Queue load balancing - optionally give highest priority to the local connection, then local broker then networks
[ https://issues.apache.org/activemq/browse/AMQ-468?page=all ] james strachan updated AMQ-468: --- Summary: Queue load balancing - optionally give highest priority to the local connection, then local broker then networks (was: Queue load balancing - optionally give highest priority to the local connection) Description: For Queues, as an option assign the highest priority for dispatching to the local connection, then the local broker, then the cluster etc. Right now we favour consumers on the local broker above consumers on remote brokers. However we should prioritise consumers on the same session, connection or VM transport above consumers in other processes etc was:For Queues, as an option assign the highest priority for dispatching to the local connection, then the local broker, then the cluster etc. Queue load balancing - optionally give highest priority to the local connection, then local broker then networks Key: AMQ-468 URL: https://issues.apache.org/activemq/browse/AMQ-468 Project: ActiveMQ Type: Improvement Reporter: Rob Davies Fix For: 4.1 For Queues, as an option assign the highest priority for dispatching to the local connection, then the local broker, then the cluster etc. Right now we favour consumers on the local broker above consumers on remote brokers. However we should prioritise consumers on the same session, connection or VM transport above consumers in other processes etc -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-468) Queue load balancing - optionally give highest priority to the local connection, then local broker then networks
[ https://issues.apache.org/activemq/browse/AMQ-468?page=comments#action_36504 ] james strachan commented on AMQ-468: We mght want to weight consumers via * the session (so replies tend to go to the session which sent a message) * the connection that sent the message * VM connections (which are generally cheaper to use) I guess we might want this to be configurable. Queue load balancing - optionally give highest priority to the local connection, then local broker then networks Key: AMQ-468 URL: https://issues.apache.org/activemq/browse/AMQ-468 Project: ActiveMQ Type: Improvement Reporter: Rob Davies Fix For: 4.1 For Queues, as an option assign the highest priority for dispatching to the local connection, then the local broker, then the cluster etc. Right now we favour consumers on the local broker above consumers on remote brokers. However we should prioritise consumers on the same session, connection or VM transport above consumers in other processes etc -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-762) Message Group based load balancing not well distributed across brokers
Message Group based load balancing not well distributed across brokers -- Key: AMQ-762 URL: https://issues.apache.org/activemq/browse/AMQ-762 Project: ActiveMQ Type: Bug Versions: 4.0 Environment: Active MQ 4.0, Lingo 1.1 Reporter: Sanjiv Jivan Attachments: lingocluster.zip I started 2 servers, each of which have an embedded broker. A shell based chield sends messages to 30 different message groups (using command register message group in the samepl app provided. Only 2 mesages are received by server1, 3 by server2 and 25 by server3. The load balancing distribution is highly unenen. As suggested, I also tried setting a low destination queue prefetch value (consumer.prefetch=1) but the result was the same. To run sample : 1. Unzip attached file and run maven.bat from the oot directory (Maven 1.0) 2. Open 3 DOS boxes in the dist\bin folder and run startoptimizerPooled.bat, startOptimizerPooled2.bat and startOptimizerPooled3.bat in each DOS box respectively. 3. Step 2 starts a network of 3 servers apps which have an embedded broker. The Spring configuration files for each of these servers is in the dist\conf directory. 4. Open another DOS box in dist\bin and start a test client by running startClientShell.bat 5. This command driver test client accepts commads in the form register message group close message group and exit NOTE: The command close message group is supposed to close/reset the message group by issueing a JMSXGroupSeq header as described here : http://www.activemq.org/site/message-groups.html 6. Try sending several messages to the server by issuing several commands like regeister A, register B, register C and so on.. You'll see the highly uneven distibution of messages. Only one or two messages are received my 2 servers while the third one receives a majority of the messages. Please let me know if you have trouble running the sample or replicating the issue. Thanks, Sanjiv -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
