From 88f4f04b32cf1024a9ce84db54a986950c1e7499 Mon Sep 17 00:00:00 2001 From: Aidan Skinner Date: Mon, 2 Jun 2008 18:12:47 +0000 Subject: Move to documentation directory git-svn-id: https://svn.apache.org/repos/asf/incubator/qpid/branches/forrest-site@662505 13f79535-47bb-0310-9956-ffa450edef68 --- documentation/classes/CatalogManager.properties | 62 + documentation/content/locationmap.xml | 72 + .../content/xdocs/0.10 Connection URL Format.html | 107 ++ .../content/xdocs/3rd Party Libraries.html | 129 ++ .../M1-bdbstore.jar | Bin 0 -> 18784 bytes .../M2-bdbstore.jar | Bin 0 -> 48190 bytes .../content/xdocs/AMQP0-9-DesignNotes.html | 69 + documentation/content/xdocs/AMQPVersion.1.html | 176 +++ documentation/content/xdocs/Acknowledgment.html | 66 + .../xdocs/Acknowledgment_attachments/jprofiler.png | Bin 0 -> 584 bytes .../Acknowledgment_attachments/structure101.jpg | Bin 0 -> 3465 bytes .../content/xdocs/BDBMessageStore (3rd Party).html | 48 + .../content/xdocs/BewareOfStringPromotion.html | 59 + .../content/xdocs/BewareStdStringLiterals.html | 69 + documentation/content/xdocs/BindingURLFormat.html | 100 ++ documentation/content/xdocs/Build .NET Client.html | 58 + documentation/content/xdocs/Building.html | 99 ++ .../content/xdocs/Cluster Design Note.html | 671 +++++++++ .../content/xdocs/ClusteringAndFederation.html | 135 ++ documentation/content/xdocs/ClusteringHA.html | 66 + documentation/content/xdocs/Configure ACLs.html | 40 + ...nfigure Java Qpid to use a SSL connection..html | 64 + .../xdocs/Configure the Broker via config.xml.html | 51 + ...ure the Virtual Hosts via virtualhosts.xml.html | 113 ++ .../xdocs/Configuring Qpid Management Console.html | 105 ++ .../content/xdocs/Connection URL Format.html | 167 +++ .../xdocs/Cpp Client Java Interop Issues.html | 71 + documentation/content/xdocs/CppApiGuide.html | 82 ++ documentation/content/xdocs/CppEventChannelIo.html | 167 +++ documentation/content/xdocs/CppHandlerChains.html | 76 + documentation/content/xdocs/CppStyleGuide.html | 86 ++ documentation/content/xdocs/CppTips.html | 55 + documentation/content/xdocs/Developer Pages.html | 82 ++ .../merege_test_output.txt | 470 ++++++ .../content/xdocs/Distributed Testing.html | 379 +++++ documentation/content/xdocs/Download.html | 84 ++ documentation/content/xdocs/Example Classes.html | 119 ++ documentation/content/xdocs/FAQ.html | 79 + documentation/content/xdocs/GSoC.html | 182 +++ documentation/content/xdocs/Getting Involved.html | 80 ++ .../content/xdocs/Getting Started Guide.html | 250 ++++ .../set_classpath.bat | 50 + .../set_classpath.sh | 83 ++ documentation/content/xdocs/Getting Started.html | 96 ++ documentation/content/xdocs/HermesJMS.html | 98 ++ documentation/content/xdocs/How to Use JNDI.html | 124 ++ .../Informal M2.1 code review 2008-03-18.html | 42 + .../xdocs/Interop Testing Specification.html | 1106 ++++++++++++++ documentation/content/xdocs/JDBCStore.html | 38 + documentation/content/xdocs/JMS Compliance.html | 41 + .../content/xdocs/JMX Management Console.html | 64 + .../Qpid_Management_Console.doc | Bin 0 -> 433664 bytes .../Qpid_using_jconsole.doc | Bin 0 -> 228864 bytes .../content/xdocs/Java Architecture Overview.html | 46 + .../Qpid-architecture.png | Bin 0 -> 35903 bytes .../xdocs/Java Broker Design - MessageStore.html | 39 + .../content/xdocs/Java Coding Standards.html | 406 ++++++ .../xdocs/Java Unit Tests with InVM Broker.html | 84 ++ documentation/content/xdocs/License.html | 100 ++ .../content/xdocs/Low-Level API Diagram.html | 46 + .../Low-Level API Diagram_attachments/api.GIF | Bin 0 -> 9817 bytes .../content/xdocs/M1 Release Check list.html | 97 ++ documentation/content/xdocs/M1 Release.html | 51 + documentation/content/xdocs/M2 - config.xml.html | 249 ++++ documentation/content/xdocs/M2 Release.html | 112 ++ documentation/content/xdocs/M2.1 - config.xml.html | 266 ++++ documentation/content/xdocs/Mailing Lists.html | 67 + .../content/xdocs/Management Design notes.html | 714 +++++++++ .../QpidMgmtSchema.xml | 268 ++++ documentation/content/xdocs/Management Tools.html | 45 + documentation/content/xdocs/MartinRitchie.html | 36 + .../content/xdocs/MemoryMessageStore.html | 38 + .../content/xdocs/Message API Design.html | 182 +++ documentation/content/xdocs/MessageStore Tool.html | 115 ++ documentation/content/xdocs/MgmtC++.html | 333 +++++ .../xdocs/Multiple AMQP Version Support.html | 192 +++ .../AmqpDomainMap.png | Bin 0 -> 3527 bytes .../AmqpModel.png | Bin 0 -> 9573 bytes documentation/content/xdocs/Navigation.html | 77 + .../AMQP_logo_71px-small.jpg | Bin 0 -> 2513 bytes .../apache-incubator-logo-small.png | Bin 0 -> 1738 bytes .../xdocs/NeverUseStaticLocalVariables.html | 48 + .../content/xdocs/NoUsingNamespaceInHeaders.html | 49 + documentation/content/xdocs/OSVC.html | 137 ++ .../content/xdocs/Old Clustering Design Note.html | 185 +++ documentation/content/xdocs/People.html | 110 ++ .../content/xdocs/Performance Testing for C++.html | 155 ++ documentation/content/xdocs/PrivateLocking.html | 40 + documentation/content/xdocs/Project Status.html | 120 ++ .../apache-incubator-logo.png | Bin 0 -> 4234 bytes documentation/content/xdocs/Properties.xml | 124 ++ documentation/content/xdocs/PythonBrokerTest.html | 66 + .../content/xdocs/Qpid 'C++' Documentation.html | 65 + .../content/xdocs/Qpid .Net Documentation.html | 68 + documentation/content/xdocs/Qpid .Net How To.html | 41 + .../content/xdocs/Qpid Cpp Build How To.html | 80 ++ .../xdocs/Qpid Design - Access Control Lists.html | 44 + .../xdocs/Qpid Design - Application Registry.html | 52 + .../xdocs/Qpid Design - Authentication.html | 160 +++ .../content/xdocs/Qpid Design - Configuration.html | 166 +++ .../content/xdocs/Qpid Design - Framing.html | 75 + .../DecodingClasses.gif | Bin 0 -> 9529 bytes .../FramingClassDiagram.gif | Bin 0 -> 26176 bytes .../content/xdocs/Qpid Design - Management.html | 45 + .../Qpid Design - Message Acknowledgement.html | 118 ++ .../content/xdocs/Qpid Design - Threading.html | 74 + .../QpidThreadingModel.gif | Bin 0 -> 52166 bytes .../xdocs/Qpid Developer Documentation.html | 38 + .../Qpid IBM JMS Performance Test Results.html | 129 ++ .../content/xdocs/Qpid Java Build How To.html | 318 ++++ .../mavenlinks.html | 11 + .../xdocs/Qpid Java Client refactoring.html | 59 + .../java_amqp_client_design.pdf | Bin 0 -> 427271 bytes .../content/xdocs/Qpid Java Documentation.html | 108 ++ documentation/content/xdocs/Qpid Java FAQ.html | 330 +++++ .../xdocs/Qpid Java FAQ_attachments/appContext.zip | Bin 0 -> 987 bytes documentation/content/xdocs/Qpid Java How To.html | 41 + .../content/xdocs/Qpid Java M1 Release Notes.html | 66 + .../Qpid Java Meeting Minutes 04-04-2008.html | 559 ++++++++ .../Qpid Java Meeting Minutes 11-04-2008.html | 513 +++++++ .../Qpid Java Meeting Minutes 2008-04-18.html | 945 ++++++++++++ .../Qpid Java Meeting Minutes 28-03-2008.html | 111 ++ .../content/xdocs/Qpid Java Run Scripts.html | 178 +++ .../content/xdocs/Qpid Management Features.html | 100 ++ .../content/xdocs/Qpid Python Documentation.html | 40 + .../content/xdocs/Qpid Release Notes.html | 36 + documentation/content/xdocs/Qpid Release Page.html | 60 + .../content/xdocs/Qpid Ruby Documentation.html | 36 + documentation/content/xdocs/Qpid Testing.html | 88 ++ .../content/xdocs/Qpid Troubleshooting Guide.html | 83 ++ .../content/xdocs/QpidReleaseProcess.html | 178 +++ documentation/content/xdocs/Queue Replay.html | 190 +++ .../Queue Replay_attachments/ReplayableQueue.gif | Bin 0 -> 6730 bytes .../Queue Replay_attachments/TraditionalQueue.gif | Bin 0 -> 8851 bytes .../TraditionalQueueWithTX.gif | Bin 0 -> 14020 bytes documentation/content/xdocs/RAJB.html | 47 + documentation/content/xdocs/RASC.html | 191 +++ .../content/xdocs/RC Multi-Platform Testing.html | 48 + documentation/content/xdocs/Release Plans.html | 46 + .../content/xdocs/Reliability Requirements.html | 96 ++ .../AMQ Frame handling | 1 + .../ContentHandlerTree.jpg | Bin 0 -> 57476 bytes .../DispatchTree.jpg | Bin 0 -> 42746 bytes .../MethodHandlerTree.jpg | Bin 0 -> 46275 bytes .../content/xdocs/ReturnStdStringByValue.html | 54 + documentation/content/xdocs/ScopedLocking.html | 52 + .../xdocs/Setup .Net Client on Windows.html | 50 + documentation/content/xdocs/SharedPtr.html | 71 + documentation/content/xdocs/Source Repository.html | 63 + documentation/content/xdocs/Sustained Tests.html | 98 ++ documentation/content/xdocs/Test Server 1.html | 100 ++ documentation/content/xdocs/Test Server 2.html | 98 ++ .../The AMQP Distributed Transaction Classes.html | 83 ++ .../12358547_thumb_dtx.gif | Bin 0 -> 10538 bytes ...dtx-classes-presentation-v0.10-PMC-03142007.pdf | Bin 0 -> 472309 bytes .../dtx-classes-specification-document-v1.2.pdf | Bin 0 -> 390243 bytes documentation/content/xdocs/Topic Test.html | 109 ++ documentation/content/xdocs/URL Formats.html | 43 + documentation/content/xdocs/Useful Links.html | 38 + .../Using Qpid with other JNDI Providers.html | 137 ++ .../content/xdocs/ValgrindBadSuppressions.html | 61 + .../xdocs/Weekly QPID Developer Meetings.html | 36 + documentation/content/xdocs/add.gif | Bin 0 -> 318 bytes .../content/xdocs/border/border_bottom.gif | Bin 0 -> 117 bytes documentation/content/xdocs/border/spacer.gif | Bin 0 -> 43 bytes documentation/content/xdocs/icons/blogentry_16.gif | Bin 0 -> 268 bytes documentation/content/xdocs/icons/bullet_blue.gif | Bin 0 -> 60 bytes documentation/content/xdocs/icons/comment_16.gif | Bin 0 -> 178 bytes .../content/xdocs/icons/emoticons/add.gif | Bin 0 -> 599 bytes .../content/xdocs/icons/emoticons/biggrin.gif | Bin 0 -> 696 bytes .../content/xdocs/icons/emoticons/check.gif | Bin 0 -> 604 bytes .../content/xdocs/icons/emoticons/error.gif | Bin 0 -> 633 bytes .../content/xdocs/icons/emoticons/forbidden.gif | Bin 0 -> 613 bytes .../content/xdocs/icons/emoticons/help_16.gif | Bin 0 -> 634 bytes .../content/xdocs/icons/emoticons/information.gif | Bin 0 -> 1005 bytes .../content/xdocs/icons/emoticons/lightbulb.gif | Bin 0 -> 350 bytes .../content/xdocs/icons/emoticons/lightbulb_on.gif | Bin 0 -> 551 bytes .../content/xdocs/icons/emoticons/sad.gif | Bin 0 -> 698 bytes .../content/xdocs/icons/emoticons/smile.gif | Bin 0 -> 699 bytes .../content/xdocs/icons/emoticons/star_blue.gif | Bin 0 -> 569 bytes .../content/xdocs/icons/emoticons/star_green.gif | Bin 0 -> 569 bytes .../content/xdocs/icons/emoticons/star_red.gif | Bin 0 -> 567 bytes .../content/xdocs/icons/emoticons/star_yellow.gif | Bin 0 -> 567 bytes .../content/xdocs/icons/emoticons/thumbs_down.gif | Bin 0 -> 283 bytes .../content/xdocs/icons/emoticons/thumbs_up.gif | Bin 0 -> 280 bytes .../content/xdocs/icons/emoticons/tongue.gif | Bin 0 -> 698 bytes .../content/xdocs/icons/emoticons/warning.gif | Bin 0 -> 569 bytes .../content/xdocs/icons/emoticons/wink.gif | Bin 0 -> 698 bytes documentation/content/xdocs/icons/home_16.gif | Bin 0 -> 594 bytes documentation/content/xdocs/icons/linkext7.gif | Bin 0 -> 166 bytes documentation/content/xdocs/icons/mail_16.gif | Bin 0 -> 381 bytes documentation/content/xdocs/icons/mail_small.gif | Bin 0 -> 202 bytes documentation/content/xdocs/icons/user_12.gif | Bin 0 -> 528 bytes documentation/content/xdocs/icons/user_16.gif | Bin 0 -> 1008 bytes documentation/content/xdocs/index.html | 709 +++++++++ documentation/content/xdocs/reconnect.gif | Bin 0 -> 327 bytes documentation/content/xdocs/roadmap.html | 100 ++ documentation/content/xdocs/site.xml | 146 ++ documentation/content/xdocs/styles/site.css | 1511 ++++++++++++++++++++ documentation/content/xdocs/tabs.xml | 36 + documentation/resources/images/ellipse-2.svg | 30 + documentation/resources/images/icon-a.png | Bin 0 -> 2092 bytes documentation/resources/images/icon-b.png | Bin 0 -> 2055 bytes documentation/resources/images/icon.png | Bin 0 -> 696 bytes documentation/resources/images/project-logo.png | Bin 0 -> 4633 bytes documentation/resources/images/sub-dir/icon-c.png | Bin 0 -> 2042 bytes documentation/resources/schema/catalog.xcat | 29 + documentation/resources/schema/hello-v10.dtd | 51 + .../resources/schema/symbols-project-v10.ent | 26 + .../resources/stylesheets/hello2document.xsl | 33 + documentation/sitemap.xmap | 66 + documentation/skinconf.xml | 416 ++++++ documentation/translations/langcode.xml | 29 + documentation/translations/languages_de.xml | 24 + documentation/translations/languages_en.xml | 24 + documentation/translations/languages_es.xml | 22 + documentation/translations/languages_fr.xml | 24 + documentation/translations/languages_nl.xml | 24 + documentation/translations/menu.xml | 33 + documentation/translations/menu_af.xml | 33 + documentation/translations/menu_de.xml | 33 + documentation/translations/menu_es.xml | 33 + documentation/translations/menu_fr.xml | 33 + documentation/translations/menu_it.xml | 33 + documentation/translations/menu_nl.xml | 33 + documentation/translations/menu_no.xml | 33 + documentation/translations/menu_ru.xml | 33 + documentation/translations/menu_sk.xml | 33 + documentation/translations/tabs.xml | 22 + documentation/translations/tabs_de.xml | 22 + documentation/translations/tabs_es.xml | 22 + documentation/translations/tabs_fr.xml | 22 + documentation/translations/tabs_nl.xml | 22 + 233 files changed, 21594 insertions(+) create mode 100755 documentation/classes/CatalogManager.properties create mode 100755 documentation/content/locationmap.xml create mode 100755 documentation/content/xdocs/0.10 Connection URL Format.html create mode 100755 documentation/content/xdocs/3rd Party Libraries.html create mode 100755 documentation/content/xdocs/3rd Party Libraries_attachments/M1-bdbstore.jar create mode 100755 documentation/content/xdocs/3rd Party Libraries_attachments/M2-bdbstore.jar create mode 100755 documentation/content/xdocs/AMQP0-9-DesignNotes.html create mode 100755 documentation/content/xdocs/AMQPVersion.1.html create mode 100755 documentation/content/xdocs/Acknowledgment.html create mode 100755 documentation/content/xdocs/Acknowledgment_attachments/jprofiler.png create mode 100755 documentation/content/xdocs/Acknowledgment_attachments/structure101.jpg create mode 100755 documentation/content/xdocs/BDBMessageStore (3rd Party).html create mode 100755 documentation/content/xdocs/BewareOfStringPromotion.html create mode 100755 documentation/content/xdocs/BewareStdStringLiterals.html create mode 100755 documentation/content/xdocs/BindingURLFormat.html create mode 100755 documentation/content/xdocs/Build .NET Client.html create mode 100755 documentation/content/xdocs/Building.html create mode 100755 documentation/content/xdocs/Cluster Design Note.html create mode 100755 documentation/content/xdocs/ClusteringAndFederation.html create mode 100755 documentation/content/xdocs/ClusteringHA.html create mode 100755 documentation/content/xdocs/Configure ACLs.html create mode 100755 documentation/content/xdocs/Configure Java Qpid to use a SSL connection..html create mode 100644 documentation/content/xdocs/Configure the Broker via config.xml.html create mode 100755 documentation/content/xdocs/Configure the Virtual Hosts via virtualhosts.xml.html create mode 100755 documentation/content/xdocs/Configuring Qpid Management Console.html create mode 100755 documentation/content/xdocs/Connection URL Format.html create mode 100755 documentation/content/xdocs/Cpp Client Java Interop Issues.html create mode 100755 documentation/content/xdocs/CppApiGuide.html create mode 100755 documentation/content/xdocs/CppEventChannelIo.html create mode 100755 documentation/content/xdocs/CppHandlerChains.html create mode 100755 documentation/content/xdocs/CppStyleGuide.html create mode 100755 documentation/content/xdocs/CppTips.html create mode 100755 documentation/content/xdocs/Developer Pages.html create mode 100755 documentation/content/xdocs/Developer Pages_attachments/merege_test_output.txt create mode 100755 documentation/content/xdocs/Distributed Testing.html create mode 100755 documentation/content/xdocs/Download.html create mode 100755 documentation/content/xdocs/Example Classes.html create mode 100755 documentation/content/xdocs/FAQ.html create mode 100755 documentation/content/xdocs/GSoC.html create mode 100755 documentation/content/xdocs/Getting Involved.html create mode 100755 documentation/content/xdocs/Getting Started Guide.html create mode 100755 documentation/content/xdocs/Getting Started Guide_attachments/set_classpath.bat create mode 100755 documentation/content/xdocs/Getting Started Guide_attachments/set_classpath.sh create mode 100755 documentation/content/xdocs/Getting Started.html create mode 100755 documentation/content/xdocs/HermesJMS.html create mode 100755 documentation/content/xdocs/How to Use JNDI.html create mode 100755 documentation/content/xdocs/Informal M2.1 code review 2008-03-18.html create mode 100755 documentation/content/xdocs/Interop Testing Specification.html create mode 100755 documentation/content/xdocs/JDBCStore.html create mode 100755 documentation/content/xdocs/JMS Compliance.html create mode 100755 documentation/content/xdocs/JMX Management Console.html create mode 100755 documentation/content/xdocs/JMX Management Console_attachments/Qpid_Management_Console.doc create mode 100755 documentation/content/xdocs/JMX Management Console_attachments/Qpid_using_jconsole.doc create mode 100755 documentation/content/xdocs/Java Architecture Overview.html create mode 100755 documentation/content/xdocs/Java Architecture Overview_attachments/Qpid-architecture.png create mode 100755 documentation/content/xdocs/Java Broker Design - MessageStore.html create mode 100755 documentation/content/xdocs/Java Coding Standards.html create mode 100755 documentation/content/xdocs/Java Unit Tests with InVM Broker.html create mode 100755 documentation/content/xdocs/License.html create mode 100755 documentation/content/xdocs/Low-Level API Diagram.html create mode 100755 documentation/content/xdocs/Low-Level API Diagram_attachments/api.GIF create mode 100755 documentation/content/xdocs/M1 Release Check list.html create mode 100755 documentation/content/xdocs/M1 Release.html create mode 100644 documentation/content/xdocs/M2 - config.xml.html create mode 100755 documentation/content/xdocs/M2 Release.html create mode 100755 documentation/content/xdocs/M2.1 - config.xml.html create mode 100755 documentation/content/xdocs/Mailing Lists.html create mode 100755 documentation/content/xdocs/Management Design notes.html create mode 100755 documentation/content/xdocs/Management Design notes_attachments/QpidMgmtSchema.xml create mode 100755 documentation/content/xdocs/Management Tools.html create mode 100755 documentation/content/xdocs/MartinRitchie.html create mode 100755 documentation/content/xdocs/MemoryMessageStore.html create mode 100755 documentation/content/xdocs/Message API Design.html create mode 100755 documentation/content/xdocs/MessageStore Tool.html create mode 100755 documentation/content/xdocs/MgmtC++.html create mode 100755 documentation/content/xdocs/Multiple AMQP Version Support.html create mode 100755 documentation/content/xdocs/Multiple AMQP Version Support_attachments/AmqpDomainMap.png create mode 100755 documentation/content/xdocs/Multiple AMQP Version Support_attachments/AmqpModel.png create mode 100755 documentation/content/xdocs/Navigation.html create mode 100755 documentation/content/xdocs/Navigation_attachments/AMQP_logo_71px-small.jpg create mode 100755 documentation/content/xdocs/Navigation_attachments/apache-incubator-logo-small.png create mode 100755 documentation/content/xdocs/NeverUseStaticLocalVariables.html create mode 100755 documentation/content/xdocs/NoUsingNamespaceInHeaders.html create mode 100755 documentation/content/xdocs/OSVC.html create mode 100755 documentation/content/xdocs/Old Clustering Design Note.html create mode 100755 documentation/content/xdocs/People.html create mode 100755 documentation/content/xdocs/Performance Testing for C++.html create mode 100755 documentation/content/xdocs/PrivateLocking.html create mode 100755 documentation/content/xdocs/Project Status.html create mode 100755 documentation/content/xdocs/Project Status_attachments/apache-incubator-logo.png create mode 100755 documentation/content/xdocs/Properties.xml create mode 100755 documentation/content/xdocs/PythonBrokerTest.html create mode 100755 documentation/content/xdocs/Qpid 'C++' Documentation.html create mode 100755 documentation/content/xdocs/Qpid .Net Documentation.html create mode 100755 documentation/content/xdocs/Qpid .Net How To.html create mode 100755 documentation/content/xdocs/Qpid Cpp Build How To.html create mode 100755 documentation/content/xdocs/Qpid Design - Access Control Lists.html create mode 100755 documentation/content/xdocs/Qpid Design - Application Registry.html create mode 100755 documentation/content/xdocs/Qpid Design - Authentication.html create mode 100755 documentation/content/xdocs/Qpid Design - Configuration.html create mode 100644 documentation/content/xdocs/Qpid Design - Framing.html create mode 100755 documentation/content/xdocs/Qpid Design - Framing_attachments/DecodingClasses.gif create mode 100755 documentation/content/xdocs/Qpid Design - Framing_attachments/FramingClassDiagram.gif create mode 100755 documentation/content/xdocs/Qpid Design - Management.html create mode 100755 documentation/content/xdocs/Qpid Design - Message Acknowledgement.html create mode 100755 documentation/content/xdocs/Qpid Design - Threading.html create mode 100755 documentation/content/xdocs/Qpid Design - Threading_attachments/QpidThreadingModel.gif create mode 100755 documentation/content/xdocs/Qpid Developer Documentation.html create mode 100755 documentation/content/xdocs/Qpid IBM JMS Performance Test Results.html create mode 100755 documentation/content/xdocs/Qpid Java Build How To.html create mode 100755 documentation/content/xdocs/Qpid Java Build How To_attachments/mavenlinks.html create mode 100755 documentation/content/xdocs/Qpid Java Client refactoring.html create mode 100755 documentation/content/xdocs/Qpid Java Client refactoring_attachments/java_amqp_client_design.pdf create mode 100755 documentation/content/xdocs/Qpid Java Documentation.html create mode 100755 documentation/content/xdocs/Qpid Java FAQ.html create mode 100755 documentation/content/xdocs/Qpid Java FAQ_attachments/appContext.zip create mode 100755 documentation/content/xdocs/Qpid Java How To.html create mode 100755 documentation/content/xdocs/Qpid Java M1 Release Notes.html create mode 100755 documentation/content/xdocs/Qpid Java Meeting Minutes 04-04-2008.html create mode 100755 documentation/content/xdocs/Qpid Java Meeting Minutes 11-04-2008.html create mode 100755 documentation/content/xdocs/Qpid Java Meeting Minutes 2008-04-18.html create mode 100755 documentation/content/xdocs/Qpid Java Meeting Minutes 28-03-2008.html create mode 100644 documentation/content/xdocs/Qpid Java Run Scripts.html create mode 100755 documentation/content/xdocs/Qpid Management Features.html create mode 100755 documentation/content/xdocs/Qpid Python Documentation.html create mode 100755 documentation/content/xdocs/Qpid Release Notes.html create mode 100755 documentation/content/xdocs/Qpid Release Page.html create mode 100755 documentation/content/xdocs/Qpid Ruby Documentation.html create mode 100755 documentation/content/xdocs/Qpid Testing.html create mode 100755 documentation/content/xdocs/Qpid Troubleshooting Guide.html create mode 100755 documentation/content/xdocs/QpidReleaseProcess.html create mode 100755 documentation/content/xdocs/Queue Replay.html create mode 100755 documentation/content/xdocs/Queue Replay_attachments/ReplayableQueue.gif create mode 100755 documentation/content/xdocs/Queue Replay_attachments/TraditionalQueue.gif create mode 100755 documentation/content/xdocs/Queue Replay_attachments/TraditionalQueueWithTX.gif create mode 100755 documentation/content/xdocs/RAJB.html create mode 100755 documentation/content/xdocs/RASC.html create mode 100755 documentation/content/xdocs/RC Multi-Platform Testing.html create mode 100755 documentation/content/xdocs/Release Plans.html create mode 100755 documentation/content/xdocs/Reliability Requirements.html create mode 100755 documentation/content/xdocs/Restructuring Java Broker and Client Design_attachments/AMQ Frame handling create mode 100755 documentation/content/xdocs/Restructuring Java Broker and Client Design_attachments/ContentHandlerTree.jpg create mode 100755 documentation/content/xdocs/Restructuring Java Broker and Client Design_attachments/DispatchTree.jpg create mode 100755 documentation/content/xdocs/Restructuring Java Broker and Client Design_attachments/MethodHandlerTree.jpg create mode 100755 documentation/content/xdocs/ReturnStdStringByValue.html create mode 100755 documentation/content/xdocs/ScopedLocking.html create mode 100755 documentation/content/xdocs/Setup .Net Client on Windows.html create mode 100755 documentation/content/xdocs/SharedPtr.html create mode 100755 documentation/content/xdocs/Source Repository.html create mode 100755 documentation/content/xdocs/Sustained Tests.html create mode 100755 documentation/content/xdocs/Test Server 1.html create mode 100755 documentation/content/xdocs/Test Server 2.html create mode 100755 documentation/content/xdocs/The AMQP Distributed Transaction Classes.html create mode 100755 documentation/content/xdocs/The AMQP Distributed Transaction Classes_attachments/12358547_thumb_dtx.gif create mode 100755 documentation/content/xdocs/The AMQP Distributed Transaction Classes_attachments/dtx-classes-presentation-v0.10-PMC-03142007.pdf create mode 100755 documentation/content/xdocs/The AMQP Distributed Transaction Classes_attachments/dtx-classes-specification-document-v1.2.pdf create mode 100755 documentation/content/xdocs/Topic Test.html create mode 100755 documentation/content/xdocs/URL Formats.html create mode 100755 documentation/content/xdocs/Useful Links.html create mode 100755 documentation/content/xdocs/Using Qpid with other JNDI Providers.html create mode 100755 documentation/content/xdocs/ValgrindBadSuppressions.html create mode 100755 documentation/content/xdocs/Weekly QPID Developer Meetings.html create mode 100755 documentation/content/xdocs/add.gif create mode 100755 documentation/content/xdocs/border/border_bottom.gif create mode 100755 documentation/content/xdocs/border/spacer.gif create mode 100755 documentation/content/xdocs/icons/blogentry_16.gif create mode 100755 documentation/content/xdocs/icons/bullet_blue.gif create mode 100755 documentation/content/xdocs/icons/comment_16.gif create mode 100755 documentation/content/xdocs/icons/emoticons/add.gif create mode 100755 documentation/content/xdocs/icons/emoticons/biggrin.gif create mode 100755 documentation/content/xdocs/icons/emoticons/check.gif create mode 100755 documentation/content/xdocs/icons/emoticons/error.gif create mode 100755 documentation/content/xdocs/icons/emoticons/forbidden.gif create mode 100755 documentation/content/xdocs/icons/emoticons/help_16.gif create mode 100755 documentation/content/xdocs/icons/emoticons/information.gif create mode 100755 documentation/content/xdocs/icons/emoticons/lightbulb.gif create mode 100755 documentation/content/xdocs/icons/emoticons/lightbulb_on.gif create mode 100755 documentation/content/xdocs/icons/emoticons/sad.gif create mode 100755 documentation/content/xdocs/icons/emoticons/smile.gif create mode 100755 documentation/content/xdocs/icons/emoticons/star_blue.gif create mode 100755 documentation/content/xdocs/icons/emoticons/star_green.gif create mode 100755 documentation/content/xdocs/icons/emoticons/star_red.gif create mode 100755 documentation/content/xdocs/icons/emoticons/star_yellow.gif create mode 100755 documentation/content/xdocs/icons/emoticons/thumbs_down.gif create mode 100755 documentation/content/xdocs/icons/emoticons/thumbs_up.gif create mode 100755 documentation/content/xdocs/icons/emoticons/tongue.gif create mode 100755 documentation/content/xdocs/icons/emoticons/warning.gif create mode 100755 documentation/content/xdocs/icons/emoticons/wink.gif create mode 100755 documentation/content/xdocs/icons/home_16.gif create mode 100755 documentation/content/xdocs/icons/linkext7.gif create mode 100755 documentation/content/xdocs/icons/mail_16.gif create mode 100755 documentation/content/xdocs/icons/mail_small.gif create mode 100755 documentation/content/xdocs/icons/user_12.gif create mode 100755 documentation/content/xdocs/icons/user_16.gif create mode 100755 documentation/content/xdocs/index.html create mode 100755 documentation/content/xdocs/reconnect.gif create mode 100755 documentation/content/xdocs/roadmap.html create mode 100755 documentation/content/xdocs/site.xml create mode 100755 documentation/content/xdocs/styles/site.css create mode 100755 documentation/content/xdocs/tabs.xml create mode 100755 documentation/resources/images/ellipse-2.svg create mode 100755 documentation/resources/images/icon-a.png create mode 100755 documentation/resources/images/icon-b.png create mode 100755 documentation/resources/images/icon.png create mode 100755 documentation/resources/images/project-logo.png create mode 100755 documentation/resources/images/sub-dir/icon-c.png create mode 100755 documentation/resources/schema/catalog.xcat create mode 100755 documentation/resources/schema/hello-v10.dtd create mode 100755 documentation/resources/schema/symbols-project-v10.ent create mode 100755 documentation/resources/stylesheets/hello2document.xsl create mode 100755 documentation/sitemap.xmap create mode 100755 documentation/skinconf.xml create mode 100755 documentation/translations/langcode.xml create mode 100755 documentation/translations/languages_de.xml create mode 100644 documentation/translations/languages_en.xml create mode 100755 documentation/translations/languages_es.xml create mode 100755 documentation/translations/languages_fr.xml create mode 100755 documentation/translations/languages_nl.xml create mode 100755 documentation/translations/menu.xml create mode 100755 documentation/translations/menu_af.xml create mode 100755 documentation/translations/menu_de.xml create mode 100755 documentation/translations/menu_es.xml create mode 100755 documentation/translations/menu_fr.xml create mode 100755 documentation/translations/menu_it.xml create mode 100755 documentation/translations/menu_nl.xml create mode 100755 documentation/translations/menu_no.xml create mode 100755 documentation/translations/menu_ru.xml create mode 100755 documentation/translations/menu_sk.xml create mode 100755 documentation/translations/tabs.xml create mode 100755 documentation/translations/tabs_de.xml create mode 100755 documentation/translations/tabs_es.xml create mode 100755 documentation/translations/tabs_fr.xml create mode 100755 documentation/translations/tabs_nl.xml diff --git a/documentation/classes/CatalogManager.properties b/documentation/classes/CatalogManager.properties new file mode 100755 index 0000000000..b3819241c9 --- /dev/null +++ b/documentation/classes/CatalogManager.properties @@ -0,0 +1,62 @@ +# Licensed to the Apache Software Foundation (ASF) under one or more +# contributor license agreements. See the NOTICE file distributed with +# this work for additional information regarding copyright ownership. +# The ASF licenses this file to You under the Apache License, Version 2.0 +# (the "License"); you may not use this file except in compliance with +# the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. + +#======================================================================= +# CatalogManager.properties for Catalog Entity Resolver. +# +# This is the default properties file for your project. +# This facilitates local configuration of application-specific catalogs. +# If you have defined any local catalogs, then they will be loaded +# before Forrest's core catalogs. +# +# See the Apache Forrest documentation: +# http://forrest.apache.org/docs/your-project.html +# http://forrest.apache.org/docs/validation.html + +# verbosity: +# The level of messages for status/debug (messages go to standard output). +# The setting here is for your own local catalogs. +# The verbosity of Forrest's core catalogs is controlled via +# main/webapp/WEB-INF/cocoon.xconf +# +# The following messages are provided ... +# 0 = none +# 1 = ? (... not sure yet) +# 2 = 1+, Loading catalog, Resolved public, Resolved system +# 3 = 2+, Catalog does not exist, resolvePublic, resolveSystem +# 10 = 3+, List all catalog entries when loading a catalog +# (Cocoon also logs the "Resolved public" messages.) +verbosity=1 + +# catalogs ... list of additional catalogs to load +# (Note that Apache Forrest will automatically load its own default catalog +# from main/webapp/resources/schema/catalog.xcat) +# Use either full pathnames or relative pathnames. +# pathname separator is always semi-colon (;) regardless of operating system +# directory separator is always slash (/) regardless of operating system +# The project catalog is expected to be at ../resources/schema/catalog.xcat +#catalogs=../resources/schema/catalog.xcat +# FIXME: Workaround FOR-548 "project DTD catalogs are not included +# when running as a servlet WAR". +# Same catalog, different path +catalogs=../resources/schema/catalog.xcat;../../project/src/documentation/resources/schema/catalog.xcat + +# relative-catalogs +# If false, relative catalog URIs are made absolute with respect to the +# base URI of the CatalogManager.properties file. This setting only +# applies to catalog URIs obtained from the catalogs property in the +# CatalogManager.properties file +# Example: relative-catalogs=[yes|no] +relative-catalogs=no diff --git a/documentation/content/locationmap.xml b/documentation/content/locationmap.xml new file mode 100755 index 0000000000..8ac59a9dd6 --- /dev/null +++ b/documentation/content/locationmap.xml @@ -0,0 +1,72 @@ + + + + + + + + + + + + + + + + + + + + + + diff --git a/documentation/content/xdocs/0.10 Connection URL Format.html b/documentation/content/xdocs/0.10 Connection URL Format.html new file mode 100755 index 0000000000..7f2e04ba81 --- /dev/null +++ b/documentation/content/xdocs/0.10 Connection URL Format.html @@ -0,0 +1,107 @@ + + + Apache Qpid : 0.10 Connection URL Format + + + + + + + + + +
+
+ + Apache Qpid : 0.10 Connection URL Format + +
+
+ This page last changed on Jan 30, 2008 by asimon. +
+ +
+
qpid:[<property>=<value>[;<property>=<value>]]@<transport>:<host>[:<port>] 
+
+
+ +

Currently handled properties

+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
OptionDefaultDescription
virtualhost""Set the virtual host to be used (this is currently not supported by the 0.10 c++ broker
usernameguestThe user name for the client.
passwordguestThe password used for creating a connection.
client_idauto-generatedThe client identifier used for creating a connection.
+ +

Currently handled transports

+ +

Currently only 'tcp' transport is supported. 'tls' will however be supported and additional properties like 'keystore' and 'keystorelocation' will be added. The 'vm' transport should also be supported when a 0.10 Java broker will be available.

+ + + + + + + + + + + + + + + + + +
OptionDefaultDescription
tcptrueUse a TCP connection
tlsfalseUse a tls connection
+ +

Host port

+ +

The default host port used is 5672 for 'tcp'.

+ +

Failover

+ +

It is planned to introduce a failover property for controlling how failover occurs when presented with a list of brokers. This is however not yet supported.

+ +

Sample URLs

+
+
qpid:@tcp:myHost
+qpid:client_id=myClientIDpassword=myPassword;username=myUsername@tcp:myHost:5644
+
+
+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/3rd Party Libraries.html b/documentation/content/xdocs/3rd Party Libraries.html new file mode 100755 index 0000000000..f0fe46f2d2 --- /dev/null +++ b/documentation/content/xdocs/3rd Party Libraries.html @@ -0,0 +1,129 @@ + + + Apache Qpid : 3rd Party Libraries + + + + + + + + + +
+
+ + Apache Qpid : 3rd Party Libraries + +
+
+ This page last changed on Mar 10, 2008 by ritchiem. +
+ +

Qpid Persistence Options

+ +

There are currently two options for persistence in Qpid, as shown in the table below.

+ + + + + + + + + + + + + + + + + + + + +
Persistence StyleProviderAdvantagesDisadvantages
In-MemoryQpid MemoryMessageStoreComes as part of the Qpid packageNot persistent
Berkeley DB StoreBerkeley projectAllows persistence for larger messages/volumesNot Apache licensed
+ +

Using In-Memory Persistence

+ +

Using In-Memory persistence is the default when you install Qpid and requires no additional install/configuration.

+ +

Using Berkeley DB Persistence

+ +

Install Berkeley DB

+ +

If you choose to use the Berkeley DB solution for scalability purposes then you should download & install version 3.1 from http://www.oracle.com/technology/software/products/berkeley-db/je/index.html

+ +

Amend your Qpid configuration to switch BDB on

+ +

The default Qpid configuration file can be found in the etc directory of your install and is named config.xml.

+ +

To use BDB, simply add the following element:

+ +
+
<store>
+    <class>org.apache.qpid.server.store.berkeleydb.BDBMessageStore</class>
+</store>
+
+ +

alternatively an example file is provided named persistent_config.xml

+ +

Install the Qpid bridge modules for Berkeley DB

+ +

You can either build the module from source which is available from the JBoss Site.

+ +

However, as a temporary measure, you can use the bridging modules from this page M1-BDBStore or M2-BDBStore. You should then ensure that this jar is included in the classpath for the broker (see more info below), along with the BDB jar (je-<version>.jar).

+ +

This can simply be done by editing the your classpath to add the two jars that you need and then pass an option into qpid-server to use your classpath.

+ +

So, first set your classpath to something like this:

+ +
+
CLASSPATH=$QPID_HOME/lib/qpid-incubating.jar:$QPID_HOME/lib/bdbstore.jar:$QPID_HOME/lib/je-<version>.jar
+
+
+ +

Then, run qpid-server passing the following additional flag:

+
+
qpid-server -run:external-classpath=first
+
+
+ +

You can check the classpath being used by adding an additional option to output the classpath in use:

+
+
qpid-server -run:external-classpath=first -run:print-classpath
+
+
+ +

alternatively you can edit the QPID_LIBS variable in the qpid-server script.

+ +

We hope to be able to integrate these modules into our Apache project shortly - but pending a discussion about the appropriate way to handle this process.

+ + + +
+
+ Attachments: +
+ +
+ + M1-bdbstore.jar (application/x-zip-compressed) +
+ + M2-bdbstore.jar (application/octet-stream) +
+
+ +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/3rd Party Libraries_attachments/M1-bdbstore.jar b/documentation/content/xdocs/3rd Party Libraries_attachments/M1-bdbstore.jar new file mode 100755 index 0000000000..57f7b109e7 Binary files /dev/null and b/documentation/content/xdocs/3rd Party Libraries_attachments/M1-bdbstore.jar differ diff --git a/documentation/content/xdocs/3rd Party Libraries_attachments/M2-bdbstore.jar b/documentation/content/xdocs/3rd Party Libraries_attachments/M2-bdbstore.jar new file mode 100755 index 0000000000..fa778a210e Binary files /dev/null and b/documentation/content/xdocs/3rd Party Libraries_attachments/M2-bdbstore.jar differ diff --git a/documentation/content/xdocs/AMQP0-9-DesignNotes.html b/documentation/content/xdocs/AMQP0-9-DesignNotes.html new file mode 100755 index 0000000000..f225d91848 --- /dev/null +++ b/documentation/content/xdocs/AMQP0-9-DesignNotes.html @@ -0,0 +1,69 @@ + + + Apache Qpid : AMQP0-9-DesignNotes + + + + + + + + + +
+
+ + Apache Qpid : AMQP0-9-DesignNotes + +
+
+ This page last changed on Jan 30, 2007 by kpvdr. +
+ +

Design notes for AMQP 0-9 implemenation

+ +
    +
  • Reserved field in Request frame must be set to 0.
    • +
  • Request and Response constants were added to amqp.0-9.xml
    • +
  • Request ID and Response ID must start at 1 for new channels. 0 is reserved for future use, and should not be used in normal interactions between client and server.
    • +
  • Response Mark must start at 0 for new channels.
    • +
  • Content class encoding: For inline messages (first byte = 0), a null or empty byte array may be used.
    • +
  • Content class encoding: For refs, (first byte = 1), an error or exception must be thrown if the byte array is either null or empty. It makes no sense to send a null ref.
    • +
  • Content class decoding: For inline messages (first byte = 0), is is not possible to discriminate between the null array or empty array case above that encoded it. Decode as an empty byte array, not a null. (open for discussion)
    • +
  • Content class: It may be possible to set a value for either/or null and empty values in the future - if a use-case can be made for it
    • +
  • Possible batch-handling modes should be decided upon.
    • +
  • TODO: Devise a mechanism to allow one-way requests, where no acknowledgements are sent.
    • +
+ + +

AMQP 0-9 Specification Issues

+
    +
  • Errara will be made by adding to an amqp-errata.0-9.xml file rather than by making edits directly to the specification file. These are the advantages: +
      +
    • The differences between the current specification and the spec as we use it are readily apparent.
      • +
    • Different implementations share the same specification file. Thus errors that may arise as a result of a change required for one implementation (e.g. Java) on others (e.g. C++) are controled/eliminated.
      • +
    +
    • +
  • Two constants are missing and need to be inserted as an erratum: +
    +
     <constant name = "frame-request"    value = "9" />
+ <constant name = "frame-response"   value = "10" />
+
    +
    • +
  • The Basic field Basic.type (a shortstr) was omitted from Message.transfer. However, after some discussion it was resolved that since thid field serves JMS messaging only, that it should be handled as a custom property rather than creating an XML erratum to insert it. The property name is "JMSXType".
    • +
  • The Basic field Basic.mandatory(a bit) was originally omitted form Message.transfer because its functionality would have been handled by the availability of dead-letter queues. However, they did not make it into the AMQP 0-9 speicification. Thus, Basic.mandatory has been temporarily added as the last field in Message.transfer until dead-letter queues become a reality in the specification.
    • +
+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/AMQPVersion.1.html b/documentation/content/xdocs/AMQPVersion.1.html new file mode 100755 index 0000000000..29082c82c3 --- /dev/null +++ b/documentation/content/xdocs/AMQPVersion.1.html @@ -0,0 +1,176 @@ + + + Apache Qpid : AMQPVersion.1 + + + + + + + + + +
+
+ + Apache Qpid : AMQPVersion.1 + +
+
+ This page last changed on Oct 20, 2006 by kpvdr. +
+ +

Back to Multiple AMQP Version Support

+ +

Approach to adding support for multiple AMQP versions into the broker

+

I had intended to follow approach 2 below, however after some brainstorming, a better and more efficient approach has been proposed. The following is a summary of the possible courses of action.

+ +

Kim van der Riet

+
+

1. Present status: No AMQP version discrimination.

+

ADVANTAGES:

+

a. Nothing changes in the code, and everyone keeps doing what they are already doing...

+

DISADVANTAGES:

+

a. There is no easy way of hosting more than one version of AMQP at the same time in the broker.
+ b. The code that touches the version-specific generated method body classes is scattered all over the place. This makes it difficult to maintain the code if there is a change to the AMQP protocol. In order to help conceive the scope of possible protocol changes (outside of any policy the AMQP WG may have in this regard) consider the following possible change types/scopes:

+
    +
  1. A method call (class, method, fields, types) does not change, but the use or purpose of a field changes;
    2. +
  2. A method call changes the type of one or more fields;
    3. +
  3. A method call changes the number of fields (including by removing a field from one version to the next);
    4. +
  4. A method call changes the order of the fields;
    5. +
  5. A totally new method call is added;
    6. +
  6. A method call is removed;
    7. +
  7. A class is added;
    8. +
  8. A class is removed;
    9. +
  9. Any of 5-9 above in such a way as to alter the class/method numbers of unchanged elements (e.g. a class is removed, so class Basic changes from 60 to 50)
    10. +
+ + +

2. Initial approach to solving problem: Namespace discrimination.

+

a. In this approach, each version of the protocol is generated as before, but into a namespace unique to that version.
+ b. The ProtocolSession objects are made version-aware, and carry the major and minor version numbers of the current session from the ProtocolInitiation objects used to start the session.
+ c. The points in the code where version-specific method body objects and/or calls are made are moved into a single layer - the method handlers. Static function calls are added where necessary to instantiate and/or process these objects. Since the method handlers are version-aware, they would contain the logic to select the correct namespace.
+ d. The generated code would contain additional methods which allow the fields within any method body to be accessed or set using a parametrized function call. This would aid the coding of the version-sensitive logic used in the method handlers.

+
+
      
+    +--------+       +---------+       +------------+       +---------+
+    | Broker |       |  Method |       | Generated  |       | Encoder |
+    | code   | <---> | Handler | <---> | MethodBody | <---> | Decoder |
+    |        |       | classes |       |  classes   |       | classes |
+    +--------+       +---------+       +------------+       +---------+
+       1                1 set         n sets, 1/version    1 or possibly more
+
+
+

ADVANTAGES:

+

a. Allows multiple AMQP versions to be used simultaneously in the broker.
+ b. Isolates the scope of version-specific code to the method handlers, where hand-coded logic specific to the needs of individual AMQP versions may reside. This aids maintainability in the event of additional versions being added/versions being changed.
+ c. Forces the code to choose a specific AMQP version to use the MethodBody classes.
+ d. Works using existing code-generation system (XSLT).

+

DISADVANTAGES

+

a. Code duplication: Since in most AMQP version changes, 90+% of the specification remains unchanged, the generated classes will contain mostly exact duplicates from version to version.
+ b. The ideal system of version fallback (in which default behavior is to use the latest class and to hand-code logic only where differences exist) does not operate. Each version must be handled separately whether identical or not.
+ c. The code using the parametrized function calls is more complex and not as easy to understand as direct calls.

+ +

3. Revised approach: Intelligent generation

+

a. In this approach, the limitations of the existing XSLT code generation are removed. We assume that we can compare one version of the AMQP specification to another, and generate code for the latest version and code to handle only the differences between the latest and each earlier version. To achieve this, we conceptually refactor the XML specification file so that the version information is contained inside the elements instead of outside them. Then each version of the spec is added cumulatively to create a complete map of the specification. For example, assume the following simple example:

+
AMQP 1.0:
+Basic.Consume(Ticket ticket, Queue queue, ConsumerTag consumer_tag, NoLocal no_local, NoAck no_ack, bool exclusive, bool nowait);
+AMQP 1.2:
+Basic.Consume(Ticket ticket, Queue queue, ConsumerTag consumer_tag, int no_ack, bool exclusive, bool nowait, NoLocal no_local, int priority);
+
+

+ would be refactored to something like (abbreviated):
+
<AMQP>
+  <class name="Basic>
+    <version major="1" minor="0" num="60"/>
+    <version major="1" minor="2" num="50"/>
+    <method name="Consume">
+      <version major="1" minor="0" num="20"/>
+      <version major="1" minor="2" num="20"/>
+      <field name="ticket" type="Ticket">
+        <version major="1" minor="0" num="0"/>
+        <version major="1" minor="2" num="0"/>
+      </field>
+      <field name="queue" type="Queue">
+        <version major="1" minor="0" num="1"/>
+        <version major="1" minor="2" num="1"/>
+      </field>
+      <field name="consumer_tag" type="ConsumerTag">
+        <version major="1" minor="0" num="2"/>
+        <version major="1" minor="2" num="2"/>
+      </field>
+      <field name="no_local" type="NoLocal">
+        <version major="1" minor="0" num="3"/>
+        <version major="1" minor="2" num="6"/>
+      </field>
+      <field name="no_ack" type="NoAck">
+        <version major="1" minor="0" num="4"/>
+      </field>
+      <field name="no_ack" type="int">
+        <version major="1" minor="2" num="3"/>
+      </field>
+      <field name="exclusive" type="bool">
+        <version major="1" minor="0" num="5"/>
+        <version major="1" minor="2" num="4"/>
+      </field>
+      <field name="nowait" type="bool">
+        <version major="1" minor="0" num="6"/>
+        <version major="1" minor="2" num="5"/>
+      </field>
+      <field name="priority" type="int">
+        <version major="1" minor="2" num="7"/>
+      </field>
+    </method>
+  </class>
+</AMQP>
+

+ This would result in the generation of only a single MethodBody class, and since all instances of this class are version-aware, each knows how to handle calls for a given version (pseudo-java):

+
+
class BasicConsumeBody extends AMQPMethodBody
+{
+    public int _major, _minor;
+    public BasicConsumeBody(int major, int minor) {_major = major; _minor = minor;}
+    public int getAMQPClass(){if (major == 1 && minor == 0) return 60; else return 50;} // the class number has changed!
+    public int getAMQPMethod(){return 20;}
+
+    public Ticket getTicket() {...}
+    public Queue getQueue() {...}
+    public ConsumerTag getConsumerTag() {...}
+    public NoLocal getNoLocal() {....}
+    public T getNoAck(Class<T>) {if (major == 1 && minor == 0)...} // NoAck changes type
+    public boolean getExclusive() {...}
+    public boolean getNoWait() {...}
+    public int getPriority() throws Exception {if (major != 1 || minor != 2) throw...} // Priority field is in 1.2 only
+    // also for setXXX() methods...
+}
+
+

Static functions would require major and minor to be passed to be able to operate.
+ a.#2 As before, the ProtocolSession objects are made version-aware, and carry the major and minor version numbers of the current session from the ProtocolInitiation objects used to start the session.
+ b. As before, the points in the code where version-specific method body objects and/or calls are made are moved into a single layer - the method handlers.
+ c. If different versions of a particular method have additional and/or different parameters, the generated class may be thought of as a cumulative collection of all these parameters/types. Since the object is AMQP version-aware, it is possible for the handlers to know which fields to use and/or how to initialize/handle the unused fields for any call which addresses less than all the available fields. Possible courses of action include ignoring the unused field, or initializing it with a meaningful default. Making the field members of the class public would afford this flexibility, and the get/set methods could simply be viewed as convenience methods. Where the type of a field changes, the different fields would require some kind of name-mangling to indicate their type.

+ +

ADVANTAGES

+

a. Only a single class for each method body
+ b. Single get/set method for each field
+ c. Common code is simple and remains unchanged from version to version
+ d. Where a field type changes, a Class<T> type method is used; this will break all areas in the code which used to use this method, and conveniently indicate where hand-coded logic is required.
+ e. Where there is a field that is unique to a subset of versions, auto-generated code will throw an exception if it is invoked from a session of the wrong version. The addition of the exception will break the compilation (i.e. must be caught), and will indicate places in the code where hand-coded logic will be required.
+ f. The existing handler code can remain substantially unchanged.

+ +

DISADVANTAGES

+

a. Complexity...
+ b. This generation is beyond the capabilities of XSLT (or would be inordinately difficult), and we would need to switch to either Python (or Jython) or a purpose-written Java generator to do the job.
+ c. It is not clear from the interface what field is valid in what version. There has been some discussion on name-mangling to solve this, but the general dislike for name-mangling in general and the complexities it brings seem to outweigh any advantages...

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Acknowledgment.html b/documentation/content/xdocs/Acknowledgment.html new file mode 100755 index 0000000000..de79793c88 --- /dev/null +++ b/documentation/content/xdocs/Acknowledgment.html @@ -0,0 +1,66 @@ + + + Apache Qpid : Acknowledgment + + + + + + + + + +
+
+ + Apache Qpid : Acknowledgment + +
+
+ This page last changed on Apr 11, 2008 by cctrieloff. +
+ + + + + + + + + + +

We acknowledge ej-technologies for giving us a free team license for profiling Qpid Java code.

We acknowledge Headway Software for giving us free licenses of Structure101 for analyzing and managing the architecture of Qpid Java code.

+ + +

AMQP integrations

+ + + +
+
+ Attachments: +
+ +
+ + jprofiler.png (image/png) +
+ + structure101.jpg (image/jpeg) +
+
+ +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Acknowledgment_attachments/jprofiler.png b/documentation/content/xdocs/Acknowledgment_attachments/jprofiler.png new file mode 100755 index 0000000000..7c5da2cf94 Binary files /dev/null and b/documentation/content/xdocs/Acknowledgment_attachments/jprofiler.png differ diff --git a/documentation/content/xdocs/Acknowledgment_attachments/structure101.jpg b/documentation/content/xdocs/Acknowledgment_attachments/structure101.jpg new file mode 100755 index 0000000000..9242ea9176 Binary files /dev/null and b/documentation/content/xdocs/Acknowledgment_attachments/structure101.jpg differ diff --git a/documentation/content/xdocs/BDBMessageStore (3rd Party).html b/documentation/content/xdocs/BDBMessageStore (3rd Party).html new file mode 100755 index 0000000000..619a37d247 --- /dev/null +++ b/documentation/content/xdocs/BDBMessageStore (3rd Party).html @@ -0,0 +1,48 @@ + + + Apache Qpid : BDBMessageStore (3rd Party) + + + + + + + + + +
+
+ + Apache Qpid : BDBMessageStore (3rd Party) + +
+
+ This page last changed on Jul 05, 2007 by ritchiem. +
+ +

BDBMessageStore

+ +

The BDBMessageStore module utilises the BerkelyDB to provide persistence. It is not part of the Apache Qpid distribution. However, it is listed here to provide Apache Qpid users with a complete list of available Storage Mechanisms.

+ +

Licensing

+ +

This module is available under GPL.

+ +

Download

+ +

The current build is available here:
+http://rhm.et.redhat.com/download/

+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/BewareOfStringPromotion.html b/documentation/content/xdocs/BewareOfStringPromotion.html new file mode 100755 index 0000000000..4314303ddc --- /dev/null +++ b/documentation/content/xdocs/BewareOfStringPromotion.html @@ -0,0 +1,59 @@ + + + Apache Qpid : BewareOfStringPromotion + + + + + + + + + +
+
+ + Apache Qpid : BewareOfStringPromotion + +
+
+ This page last changed on Oct 19, 2006 by mmccorma. +
+ +

std::string is a useful tool for simplifying memory management of strings and avoiding unnecessary copies by reference counting. However there is one common gotcha where it causes unnecessary copies. Consider:

+ +
+
void f(const std::string& s) { cout << s << endl };
+
+void g() {
+  for (int i = 0; i <  1000; ++i) { f("hello"); };
+}
+
+ +

This actually allocates, copies and deletes 1000 heap buffers with the string "hello"! The problem here is that "hello" is not an instance of std::string. It is a char[5] that must be converted to a temporary std::string using the appropriate constructor. However std::string always wants to manage its own memory, so the constructor allocates a new buffer and copies the string. Once f() returns and we go round the loop again the temporary is deleted along with its buffer.

+ +

Here's a better solution:

+ +
+
void f(const std::string& s) { cout << s << endl };
+namespace { const std::string hello("hello"); }
+void g() {
+  for (int i = 0; i <  1000; ++i) { f(hello); };
+}
+
+ +

This time we have a constant std::string that is created once at start up and destroyed once at shut-down. The anonymous namespace makes the constant private to this .cpp file so we wont have name clashes. (Its similar to using the static keyword on a global declaration in C, but anonymous namespaces are the preferred way to do it in modern C++)

+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/BewareStdStringLiterals.html b/documentation/content/xdocs/BewareStdStringLiterals.html new file mode 100755 index 0000000000..b8388982c0 --- /dev/null +++ b/documentation/content/xdocs/BewareStdStringLiterals.html @@ -0,0 +1,69 @@ + + + Apache Qpid : BewareStdStringLiterals + + + + + + + + + +
+
+ + Apache Qpid : BewareStdStringLiterals + +
+
+ This page last changed on Oct 19, 2006 by mmccorma. +
+ +

The short story: in C++ code using std::string never use string literals except to initialize static-scoped std::string constants.
+(And by the way: NeverUseStaticLocalVariables

+ +

The long story: std::string is all about avoiding copies. Reference counting and copy-on-write serve to maximise the sharing of a single heap-allocated char array while maintaining memory safety. When used consistently in a program it works rather nicely.

+ +

However, when mixed with classic C-style string literals std::string can actually cause needless heap-allocated copies. Consider these innocent looking constructs:

+ +
+
void f(const std::string& s);
+void g(const std::string& s = "hello");
+std::string h() { return "foo"; }
+
+void copy_surprise {
+  std::string x = "x"; // 1
+  f("y"); // 2
+  g(); // 3
+  x = h(); //4
+  while (x != "end") { ... } // 4
+}
+
+ +

Lines 1-4 all cause creation and destruction of an implicit temporary std::string to hold the literal value. Line 5 does this for every execution of the while loop. That's a new/memcpy/delete each time. The heap is a heavily used resource, in tight inner loops in multi-threaded code this can be a severe contention bottleneck that cripples scalability.

+ +

Use static class std::string constants or file-private constants instead. You can make global declarations file-private by using a nameless namespace (this is preferred over the use of the static keyword.)

+ +
+
namespace { 
+   const std::string end("end");
+}
+void f() { std::string x; while (x != end) {...} }
+
+ +

And once again NeverUseStaticLocalVariables

+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/BindingURLFormat.html b/documentation/content/xdocs/BindingURLFormat.html new file mode 100755 index 0000000000..acd2132946 --- /dev/null +++ b/documentation/content/xdocs/BindingURLFormat.html @@ -0,0 +1,100 @@ + + + Apache Qpid : BindingURLFormat + + + + + + + + + +
+
+ + Apache Qpid : BindingURLFormat + +
+
+ This page last changed on Feb 18, 2008 by aidan. +
+ +
+
<Exchange Class>://<Exchange Name>/[<Destination>]/[<Queue>][?<option>='<value>'[&<option>='<value>']]
+
+
+ +

This URL format is used for two purposes in the code base. The broker uses this in the XML configuration file to create and bind queues at broker startup. It is also used by the client as a destination.

+ +

This format was used because it allows an explicit description of exchange and queue relationship.

+ +

The Exchange Class is not normally required for client connection as clients only publish to a named exchange however if exchanges are being dynamically instantiated it will be required. The class is required for the server to instantiate an exchange.

+ +

There are a number of options that are currently defined:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
OptiontypeDescription
exclusive booleanIs this an exclusive connection
autodelete booleanShould this queue be deleted on client disconnection
durablebooleanCreate a durable queue
clientidstringUse the following client id
subscriptionbooleanCreate a subscription to this destination
routingkeystringUse this value as the routing key
+ +

Using these options in conjunction with the Binding URL format should allow future expansion as new and custom exchange types are created.

+ +

The URL format requires that at least one Queue or routingkey option be present on the URL.

+ +

The routingkey would be used to encode a topic as shown in the examples section below.

+ +

Examples

+
+
direct://amq.direct/SimpleQueue
+direct://amq.direct/UnusuallyBoundQueue?routingkey='/queue'
+topic://amq.topic?routingkey='stocks.#'
+topic://amq.topic?routingkey='stocks.nyse.ibm'
+
+
+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Build .NET Client.html b/documentation/content/xdocs/Build .NET Client.html new file mode 100755 index 0000000000..2812ee3133 --- /dev/null +++ b/documentation/content/xdocs/Build .NET Client.html @@ -0,0 +1,58 @@ + + + Apache Qpid : Build .NET Client + + + + + + + + + +
+
+ + Apache Qpid : Build .NET Client + +
+
+ This page last changed on Aug 02, 2007 by ritchiem. +
+ +

Building Client

+ +

Generate framing from /Qpid.Common/amqp.xml specificiation file:

+ +

$ build-framing

+ +

Alternatively, just switch to /Qpid.Common and run "ant" there.

+ +

You can build from Visual Studio 2005 normally. Alternatively, you
+can build debug releases for any supported framework from the
+command line using Nant:

+ +

To build .NET 2.0 executables (to bin/net-2.0):

+ +

$ build-dotnet20

+ +

To build .NET 1.1 executables (to bin/net-1.1):

+ +

$ build-dotnet11

+ +

To build for Mono on Linux (to bin/mono-2.0):

+ +

$ build-mono

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Building.html b/documentation/content/xdocs/Building.html new file mode 100755 index 0000000000..f6b4bc2b67 --- /dev/null +++ b/documentation/content/xdocs/Building.html @@ -0,0 +1,99 @@ + + + Apache Qpid : Building + + + + + + + + + +
+
+ + Apache Qpid : Building + +
+
+ This page last changed on Apr 14, 2008 by cctrieloff. +
+ +

Java Building Pages

+ +

Developer Information

+ + + + +

Performance Testing

+ + + + +

Management Interfaces

+ + + + +

C++ Building Pages

+ +

Developer Information

+ + + + + +

Performance Testing

+ + + + +

Management Interfaces

+ + + + + +

Python and Ruby obviously don't need building.

+ +

.NET Building Pages

+ +

.NET can be built under MONO, or on a Windows .NET platform

+ + + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Cluster Design Note.html b/documentation/content/xdocs/Cluster Design Note.html new file mode 100755 index 0000000000..11093d52e8 --- /dev/null +++ b/documentation/content/xdocs/Cluster Design Note.html @@ -0,0 +1,671 @@ + + + Apache Qpid : Cluster Design Note + + + + + + + + + +
+
+ + Apache Qpid : Cluster Design Note + +
+
+ This page last changed on Apr 20, 2007 by aconway. +
+ +
+ +
+
+ +
+ + +

Overview

+ +

A Qpid cluster is a "virtual AMQP broker" distributed over multiple processes on multiple hosts. The cluster can continues to provide service in the event of failures of its members.

+ +

Reliability guarantees depend on configuration, there may be configurable trade-offs between reliability and performance or hardware requirements.

+ +

Clustering is transparent to clients. Cluster clients are standard AMQP clients and use the cluster via the AMQP protocol like a standard broker. If a client is disconnected unexpectedly it can fail-over transparently to another member.

+ +

We want to address two major scenarios:

+
    +
  • Cluster backed by high-performance SAN storage.
    • +
  • Cluster with only unshared local storage on each node.
    • +
+ + +

Client side requirements

+ +

Transparent failover: the failover manager component of the Qpid client libraries provides a virtual AMQP connection. Client applications send and receive AMQP commands as if conducting an uninterrupted conversation with a single broker.

+ +

In reality the virtual connection may be a series of real network connections to different cluster members. The failover manager negotiates re-connection and state synchronization, but failover commands do not appear on the virtual connection.

+ +

Imagine an AMQP conversation as a paper tape. The real conversation may be multiple strips of torn tape. Near the tears are failover commands that the client never sees. The failover manager cuts off the ragged edges and glues pieces together into a single tape that looks like an uninterrupted conversation with a single broker.

+ +

The failover manager must present a virtual conversation consistent with the failed conversations that could have happened with a single broker. It does not have to exactly duplicate the timing or ordering of the real conversations.

+ + +

Cluster protocols

+ +

We will use two types of protocol to synchronize the cluster:

+
    +
  • Virtual synchrony: Open AIS, CPG etc.
    • +
  • Point-to-point: AMQP (with proprietary extensions) over TCP.
    • +
+ + +

We will use two persistence approaches:

+
    +
  • GFS shared storage.
    • +
  • Local unshared disk storage on a node.
    • +
+ + +

The first cluster implementation will be entirely virtual synchrony and GFS: the SAN scenario.

+ +

Next iteration will support the local store only scenario but still replicate via EVS.

+ +

Subsequent optimization iterations will use primary-backup replication and proxies to increase througput by reducing multicast packets appearing on all switch ports. Cluster membership and exchange wiring will remain on EVS.

+ +

At all stages of development there will be concrete performance tests and measurements to ensure we are really optimizing.

+ +

Initially we will use AMQP 0-9 WIP protocol using field tables and message headers to pass additional cluster info. At some point we will migrate to 0-10 which is expected to have all the features needed for clustering.

+ + +

Sessions

+ +

A session identifies a client-broker relationship that can outlive a single connection. It will be formalized in AMQPO 0-10.

+ +

Orderly closure of a connection by either peer ends the session. On Unexpected disconnect the session remains viable for some timeout period allowing the client can reconnect to the cluster and resume.

+ +

Events in the AMQP.0-8 spec that are triggered by closing a connection (e.g. deleting auto-delete queues) are instead trigged by the closure (or timeout) of a session.

+ + + +

Types of state We have to consider several kinds of state:

+ +
    +
  • Cluster Membership: Active cluster members (nodes) and data about them.
    • +
  • AMQP Wiring: Names and properties of queues, exchanges and bindings.
    • +
  • AMQP Content: Data in messages on queues.
    • +
  • Session: Conversation with a single client, including references.
    • +
+ + +

Data must be replicated and stored such that:

+
    +
  • A client knows which node(s) can be used for failover.
    • +
  • After a failover, the client can continue its session uninterruped.
    • +
  • No acknowledged messages or commands are lost.
    • +
  • No messges or commands are applied twice.
    • +
+ + + +

Cluster membership, wiring and session identities are low volume, and will be replicated using virtual synchrony so the entire cluster has a consistent picture.

+ +

Queue content is high volume so it is replicated point-to-point using primary-backup to avoid flooding the network.

+ +

Session state is potentially high volume and only relevant to a single client, so it is also replicated point-to-point.

+ +

How to choose the number and location of backup nodes for a given queue or session is an open question. Note that the choice is independent for every queue and session in principle, but in practice they will probably be grouped in some way.

+ +

The Cluster Map: Membership and Wiring

+ +

Membership, wiring and session changes are low volume. They are replicated to entire cluster symmetrically using EVS.

+ +

Wiring inclues

+
    +
  • exchange names and properties
    • +
  • queue names, properties and bindings.
    • +
+ + +

Membership data includes:

+
    +
  • address of each node
    • +
  • state of health of each node
    • +
  • primary/backup for each queue/exchange
    • +
  • session names, primary/backup for each session.
    • +
+ + + +

Proxies and Queue Content

+ +

For primary-backup replication each queue has a primary and backup node. Other nodes act as proxies to the primary. The client is unaware of the distinction, it sees an identical picture regardless of what node it connects to.

+ +

Note a single cluster member may have a mix of primary, backup and proxy queues.

+ +

TODO: Ordering issues with proxys and put-back messages (reject, transaction rollback) or selectors.

+ +

Fragmented Shared Queues

+ +

A shared queue has reduced ordering requirements and increased distribution requirements. Fragmenting a shared queue is a special type of replication. The queue is broken into a set of disjoint sub-queues each on a separate node to distribute load.

+ +

Each fragment (sub-queue) content is replicated to backups just like a normal queue, independently of the other fragments.

+ +

The fragments collaberate to create the appearance of a single queue. Fragments store incomging messges in the local queue, and serve local consumers from the local queue whenever possible. When a fragment does not have messages to satisfy its consumers it consumes messages from other fragments in the group. Proxies to a fragmented queue will consume from the "nearest" fragment if possible.

+ +

TODO: Proxies can play a more active role. Ordering guarantees, we can provide "same producer to same consumer preserves order" since messages from the same producer always go on the same fragment queue. May break down in the presence of failover unless we remember which fragment received messges from the client and proxy to the same one on the failover replica.

+ + + + +

Session State

+ +

Session state includes:

+
    +
  • open channels, channel attributes (qos, transactions etc.).
    • +
  • active consumers.
    • +
  • open references.
    • +
  • completed command history.
    • +
  • commands in flight.
    • +
  • open transactions
    • +
  • exclusive/private queues.
    • +
+ + +

The broker a client is connected to is the session primary, one or more other brokers are session backup. On failure of the primary the client fails-over to a backup as described below.

+ +

The client can also fail over to a non-backup node which retrieves session state from the backup.

+ +

The primary-backup protocol must guarantee that the backup has sufficient data to resume at all times without becoming a synchronous bottleneck.

+ +

In-flight commands

+ +

Both peers must store sent commands for possible resend and received commands to detect possible duplicates in a failover.

+ +

To keep session size finite a peer can:

+
    +
  • forget sent commands when we know the other peer has received them.
    • +
  • forget received commands when we know the other peer will not resend them.
    • +
+ + +

An algorithm to achieve this:

+ +

self_received(r):

if r.is_response: peer_received(sentr.responds\_to\_id) for s in sent0..r.process\_mark: peer_received(s)

+ +

peer_received(s):

sent.erase(s) # forget s but also... # Peer will never resend commands <= s.process_mark. for r in received0..s.process\_mark received.erase(r)

+ +

The weakest rules for interop between peers A and B are:

+ +
    +
  • A MAY forget a sent command when A knows B received it.
    • +
  • A MUST NOT re-send a command after B could know that A knows B received it.
    • +
  • A MUST remember received commands till A knows that B knows A received it.
    • +
+ + +

Or in protocol terms:

+ +
    +
  • A MAY forget sent command N when it receives a response to N.
    • +
  • A MUST NOT resend N after sending a response to a response to N.
    • +
  • A MUST remember received command N until it has both sent M responding to N and received a response to M.
    • +
+ + + +

Resuming a channel

+ +

When a channel is first opened, the broker provides a session-id. If there is a failure, the client can connect to the session backup broker and resume the channel as follows (sync code is just for illustration)

+ +

TODO does it matter if the new channel number is different from the old?

+ +
    +
  1. Client client_resume:

    send(command=channel_resume, command_id=0, session_id=resume_id, process_mark=pre_crash_process_mark) ok = receive(command=channel_ok) self_received(ok) # Clean up to peers process mark. resend() continue_session_as_normal()

    2. +
+ + +
    +
  1. Both sides resend():
      +
    1. Resend in-flight messages. for s in sent: # Careful not to respond to a command we haven't received yet. if s.is_response: until(received.contains(s.resonds_to_id)): self_received(receive()) send(s); # Original command ids and process_mark
      2. +
    +
    2. +
+ + +
    +
  1. Broker broker_received_channel_resume(r):

    session=sessionsr.session\_id self_received(r) # Up to date with peers process mark. send(command=channel_ok, command_id=0, process_mark=session.process_mark) resend() continue_session_as_normal()

    2. +
+ + + +

Replicating session state.

+ +

TODO: Need to minimize primary synchronously waiting on backup, while ensuring that the primary always knows that the backup is in a state that satisfies the clients expectations for failover. See recent email thread betwween me & gordon

+ + + + +

Mapping of AMQP commands to replication mechanisms

+ +

queue.declare/bind/delete, exchange.declare/delete

+ +

Update cluster map. Local broker creates the initial queue as primary and establishes a backup.

+ +

Private queue: backed up on the session backup.

+ +

Shared queue: local primary queue is the first primary fragment. Other brokers that receive publishes for the queue can proxy to this fragment or create their own local fragment (TODO: How do we decide?) Consumes are always served from the local fragment if possible, otherwise proxied to another fragment (TODO: load balancing algorithms to choose the appropriate fragment)

+ + +

message.transfer/basic.publish (client to broker)

+ +

Local broker evaluates the binding to determine which queue(s) receive the message.

+
    +
  • primary queues: update local queue, replicate to backup.
    • +
  • proxy queues: forward to primary
    +(When the proxy is also a backup we can optimize out the replication step.)
    • +
+ + +

If the message is delivered to more than one proxy queue on the same node, we just relay the message once. Brokers must be able to differentiate between normal message transfer and proxy/replication transfer so that when the evaluate the binding they only apply the message to local primary/backup queues respectively, and don't attempt to re-forward messages.

+ +

TODO: there are a few options:

+
    +
  • Use custom backup/proxy exchanges and pass an explicit list of queues to receive the message in the header table.
    • +
  • Use normal AQMP commands over a marked connectin/channel
    • +
  • Introduce new cluster commands.
    • +
+ + + +

message.transfer(broker to client), message.deliver

+ +
    +
  • primary: replicate deliver to backup(s) deliver to client.
    • +
  • proxy: pass through to client.
    • +
+ + +

Before sending a message to a client, the primary must be sure that the session backup 'knows' about the delivery; i.e. in the event of primary failure the backup knows about unacked messages and will be able to handle an ack or reject for it, resend or requeue it.

+ +

If we can define a clear and deterministic algorithm for message dispatch, and if we replicate all 'inputs' in order then that should be sufficient.

+ +

Selectors slightly complicate the picture, as do multiple consumers and flow control particularly for shared queues where the consumers could be from different sessions.

+ +

In the case of an exclusive or private queue all the inputs come from a single session. If all session requests are handled serially on both primary and backup then dispatch should be deterministic; if separate threads were used to process separate queues that would be lost as the allocation of delivery tags would be dependent on the interleaving of those threads.

+ +

One way of avoiding the need for deterministic dispatch would be for the primary to send a message to the backup(s) to indicate an allocation before the deliver is sent to the client. This could inform the backup of the queue in question, the message id and the delivery tag/request id. The big drawback is that it requires a round-trip to the backup before each deliver and would really affect throughput.

+ +

This looks like an area that needs some specific focus. Can we convince ourselves of a clear and deterministic dispatch algorithm, are thereother solutions that would avoid requiring this without too much synchronicity?

+ + + +

message.consume/basic.consume

+
    +
  • proxy: forward consume. No replication, client will re-establish consumers.
    • +
  • primary: register consumer.
    • +
+ + + +

basic.ack/message.ok(from client)

+
    +
  • proxy: forward
    • +
  • primary: mark message processed, replicate to backups.
    • +
+ + + +

basic.ack/message.ok(from broker)

+
    +
  • proxy: forward to client
    • +
  • client: mark message processed.
    • +
+ + + +

basic.reject / message.reject

+ +

Similar to the processing of basic.ack. However here the message might be requeued or might be moved to a dead letter queue. Ignoring the dead letter queue in the first instance, the backup would merely cancel the effect of the basic.allocate on receiving the basic.reject.

+ + +

reference.open/apppend/close (client to broker)

+
    +
  • proxy: replicate to session backup, forward to primary.
    • +
  • primary: process.
    • +
+ + + +

reference.open/apppend/close (broker to client) **

+
    +
  • primary: send open/append/close.
    • +
  • proxy: replicate to session backup, forward to client.
    • +
+ + + +

All commands

+
    +
  • proxy replicates required command history to session backup.
    • +
+ + + + +

Client-Broker Protocol

+ +

Normal AMQP with the following extensions.

+ +

Initial connection:

+
    +
  • Pass session name as 0-9 connection identifier or via arguments table.
    • +
  • Broker provides list of failover replicas in arguments table.
    • +
+ + +

During connection:

+
    +
  • Client can subscribe to a special "cluster exchange" for messages carrying updates to failover candidates.
    • +
+ + +

On failure:

+
    +
  • client chooses failover node randomly from most recent list.
    • +
  • cluster list my identify "preferred" failover candidates.
    • +
+ + +

On re-connect:

+
    +
  • 0-9 resume command identifies session.
    • +
  • Client rebuilds conversational state.
    • +
  • opens channels
    • +
  • creates consumers
    • +
  • establishes
    • +
  • replays unacknowledeged commands and continues session.
    • +
+ + +

Note: the client sends conversational state data in messages to a special system exchange. We cant simply use standard AMQP to rebuild channel state, as we will end up with channels with a different command numbering from the interrupted session. For transparency we also want to distinguish reconnection from resumed "normal" operation.

+ +

At this point the session can continue.

+ + +

Broker-Broker Protocol

+ +

Broker-broker communication uses extended AMQP over specially identified connections and channels (identified in the connection negotiation argument table.)

+ +

EVS: First implementation is entirely EVS, all members have a common shared picture of the entire cluster contents.

+ +

Proxying: acting as a proxy, a broker forwards commands from client to primary and vice versa. The proxy is as transparent and stateless as possible. A proxy must renumer channels and commands since a single incoming connection may be proxied to more than one outbound connection, so it does need to keep some state. This state is part of the session state replicated to the session backup.

+ +

Queue/fragment replication: Depends on whether AMQP or GFS is used to replicate content.

+ +

AMQP: For enqueue use AMQP transfer command to transfer content to backup(s). For dequeue use AMQP get command to indicate message removed - no data is transferfed for get over a replication channel.

+ +

TODO: this use of get is strained, it starts to look like we may need a separate replication class of commands.

+ +

GFS: Queue state is updated in journal files. On failover, the backup reconstruct queue state from the journal.

+ +

Session replication: The broker must replicate a command (and get confirmation it was replicated) before responding. For async clients this can be done in a pair of asynchronous streams, i.e. we don't have to wait for a response to command A before we forward command B.

+ +

Session data is replicated via AMQP on special connections. Primary forwards all outgoing requests and incoming responses to the session backup. Backup can track the primary request/response tables and retransmit messages.

+ +

TODO: 0-9 references force us to have heavy session backup, because message data on a reference is not associated with any queue and therefore can't be backed up in a queue backup. If references are removed in 0-10 revisit the need for session backups, we may be able to comress session data enough to store it in the cluster map.

+ + +

Persistence and Recovery

+ +

Competing failure modes:

+ +

Tibco: fast when running clean but performance over time has GC "spikes" Single journal for all queues. "holes" in log have to be garbage collected to re-use the log. 1 slow consumer affects everyone because it causes fragmentation of the log.

+ +

MQ: write to journal, write journal to DB, read from DB. Consistent & reliable but slow.

+ +

Street homegrown solutions: transient MQ with home grown persistence. Can we get more design details for these solutions?

+ + + +

Persistence overview

+ +

There are 3 reasons to persist a message:

+ +

Durable messages: must be stored to disk across broker shutdowns or failures.

+
    +
  • stored when received.
    • +
  • read during start-up.
    • +
  • must be removed after deliver.
    • +
+ + +

Reliability: recover after a crash.

+
    +
  • stored when received.
    • +
  • read during crash recovery.
    • +
  • must be removed after delivery.
    • +
+ + +

Flow-to-disk: to reduce memory use for full queues.

+
    +
  • stored when memory gets tight.
    • +
  • read when delivered.
    • +
  • must be removed after delivery.
    • +
+ + + +

Durable and reliable cases are very similar: storage time is performance-critical (blocks response to sender) but reading is not and cleanup can be done by an async thread or process.

+ +

For flow-to-disk, when queues are full, both store and reading are critical.

+ +

So it looks like the same solution will work for durable and reliable.

+ +

Flow-to-disk has different requirements but it would be desirable to re-use some or all of the durable/reliable solution. In particular if flow-to-disk is combined with durable/reliablle it would be wasteful to write the message to disk a second time - instead it would seem better to keep an in-memory index that allows messages to be read quickly from the reliable/durable store.

+ +

We also need to persist wiring (Queues/Exchanges/Bindings), but this is much less performance critical. The entire wiring model is held in memory so wiring is only read at startup, and updates are low volume and not performance-critical. A simple database should suffice.

+ + + +

Journals

+ +

Overview

+ +

A journal is a sequential record of actions taken (e.g. messages enqueued, responses sent.) sufficient to reconstruct the state of the journalled entity (e.g. queue) in the case of failure and recovery.

+ + +

TODO: Journal indexing, async journal (thruput vs. latency), journal as common API for backups and disk store?

+ +

TODO: Windows for error in journalling - how to make disk update and network ack atomic? How do other technologies handle it?

+ +

TODO: References strike again: where do they go in a journal-per-queue?

+ +

TODO: Journal per broker pros/cons

+ + +

Use of journals

+ +

For reliability and durability we will use

+
    +
  • Queue journal (per queue) records enqueue/dequeues and acknowledgements.
    • +
  • Session journal (per session) records references in progress
    • +
+ + +

The broker writes enqueue and dequeue records to the end of the active journal file. When the file reaches a fixed size it starts a new one.

+ +

A cleanup agent (thread or process) removes, recycles or compacts journal files that have no live (undelivered) messages. (References complicate the book-keeping a little but don't alter the conceptual model.)

+ +

Recovery or restart reconstructs the queue contents from the enqueue/dequeue records in the journal.

+ +

Flow-to-disk can re-use the journal framework, with a simple extension: the broker keeps an in-memory index of live messages in the journal.

+ +

If flow-to-disk is combined with reliability then messages are automatically journalled on arrival, so flow-to-disk can simply delete them from memory and use the in-memory index to read them for delivery.

+ +

Without reliability flow-to-disk is similar except that messages are only journalled if memory gets tight.

+ +

Disk thrashing: Why do we think skipping disk heads around between multiple journals will be better than seeking up and down a single journal? Are we assuming that we only need to optimize the case where long sequences of traffic tend to be for the same queue?

+ +

No write on fast consume: Optimization - if we can deliver (and get ack) faster than we write then no need to write. How does this interact with HA?

+ +

Async journalling: writing to client, writing to journal, acks from client, acks from journal are separate async streams? So if we get client ack before the journalling stream has written the journal we cancel the write? But what kind of ack info do we need? Need a diagram of interactions, failure points and responses at each point. Start simple and optimize, but dont rule out optimizations.

+ + +

What about diskless reliability?

+ +

Is memory+network replication with no disk a viable option for high-speed transient message flow? May be faster, but can't support durable messages/persistent queues. We will lose messages in total failure or multiple failures where all backups fail, but we can survive single failures and will run a lot faster than diskful.

+ + + + +

Virtual synchrony

+ +

TODO: Wiring & membership via virtual synchrony

+ +

TODO: journaling, speed. Will file-per-q really help with disk burnout?

+ + +

Configuration

+ +

Simplifying patterns Possible ways to configure a cluster:

+
    +
  • Virtual hosts as units of replication.
    • +
  • Backup rings: all primary components in a broker use the same backup broker and vice-versa. Backups form rings.
    • +
  • Broker component rinks: all the components except sessions have the same backup broker. Session backups are chosen at random so a brokers load will be distributed rather than all falling on its backup.
    • +
  • Disk management issues?
    • +
  • Shared storage issues?
    • +
+ + + +

Dynamic cluster configuration

+
    +
  • Failover: the primary use case.
    • +
  • Add node: backup, proxy, primary case?
    • +
  • Redirect clients from loaded broker (pretend failure)
    • +
  • Move queue primary from loaded broker/closer to consumers?
    • +
  • Re-start after failover.
    • +
+ + +

Issue: unit of failover/redirect is connection/channel but "working set" of queues and exchanges is unrelated. Use virtual host as unit for failover/relocation? It's also a queue namespace...

+ +

If a queue moves we have to redirect its consumers, can't redirect entire channels! Channels in the same session may move between connections. Or rather we depend on broker to proxy?

+ +

Backups: chained backups rather than multi-backup? Ring backup? What about split brain, elections, quorums etc.

+ +

Should new backups acquire state from primary, from disk or possibly both? Depends on GFS/SAN vs. commodity hw?

+ + + +

Transactions

+ +

Local transactions

+ +

AMQP offers local and distributed transactions, however in a cluster a local transaction could involve queues that are distributed across several nodes.

+ +

TODO: This complicates the model of a proxy as a simple forwarder. You cannot simply forward a local transaction involving queues on two separate primary brokers, the proxy has to be aware of the transaction.

+ +

TODO Can we use point-to-point local transactions or do we have to turn this into a dtx? If dtx, who co-ordinates? Is every broker potentially a transaction co-ordinator?

+ +

TODO: For distributed transactions, will the primary broker and its backups act as a single clustered resource manager for the resource set, or will a failure of one broker abort the transaction?

+ + +

Distributed Transactions

+ +

The prepare needs to be replicated so that if one node fails before completion another node can honour the guarantee to be able to commit or abort. It is also possibe that the work of a transaction is distributed across more than one node anyway.

+ +

I think broadcasting all dtx commands over the group communication protocol seems like the most likely way to handle this.

+ +

The session in which the commands are initiated needs to be replicated also to allow clean resumption on failover.

+ + + + +

Open Questions

+ +

Issues: double failure in backup ring: A -> B -> C. Simultaneous failure of A and B. C doesn't have the replica data to take over for A.

+ +

Java/C++ interworking - is there a requirement? Fail over from C++ to Java? Common persistence formats?

+ + + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/ClusteringAndFederation.html b/documentation/content/xdocs/ClusteringAndFederation.html new file mode 100755 index 0000000000..9bf1b10cbe --- /dev/null +++ b/documentation/content/xdocs/ClusteringAndFederation.html @@ -0,0 +1,135 @@ + + + Apache Qpid : ClusteringAndFederation + + + + + + + + + +
+
+ + Apache Qpid : ClusteringAndFederation + +
+
+ This page last changed on Oct 19, 2006 by mmccorma. +
+ +

Clustering And Federation

+ +

Each diagram below depicts a distributed network of exchanges and queues. The following notation is used in all diagrams:

+
    +
  • M: message
    • +
  • E: exchange
    • +
  • Q: queue
    • +
+ + +

Multicast

+ +
+
                     M1...Mn
+                   +--------> Q
+                   |
+                   | M1...Mn
+ M1...Mn ---> E----+--------> Q
+                   |
+                   | M1...Mn
+                   +--------> Q
+
+
+ +

Queue contents are duplicated across all queues. For this scenario PGM
+would be ideal between E and Q, or even directly between E and
+consumers.

+ +

Load Balancing

+ +
+
                     M1
+                   +--------> Q
+                   |
+                   | ...
+ M1...Mn ---> E----+--------> Q
+                   |
+                   | Mn
+                   +--------> Q
+
+
+ +

No ordering is guaranteed accross different queues. A naive
+implementation could just be an exchange doing round-robin routing or
+any algorithm of choice. A more complicated exchange could have flow
+control between each queue and the exchange.

+ +

Multiple Exchanges

+ +
+
 M? ---> E1-----+              +-----> Q1
+                |              |
+                | (n*m arrows) |
+ M? ---> E2-----+--------------+-----> Q2
+                |              |
+                |              |
+ M? ---> En-----+              +-----> Qm
+
+
+ +

Both the Load Balancing and Multicast scenarios can be extended by
+adding multiple exchange nodes wired into the same (or an overlapping)
+set of queues. One virtual mega exchange (with relaxed ordering
+semantics) could be created by segmenting client connections between
+exchanges. This could be done using a number of strategies, e.g.
+round-robin dns, name mangling, redirects.

+ +

The topologies described above could in theory be use in a variety of
+scenarios ranging from an an isolated high speed subnet with
+identically configured nodes to a loosely coupled WAN with separately
+administered nodes. In fact a single network could include exchanges
+bound to local queues, remote queues available on an isolated high
+speed subnet, and remote destinations (exchange or queue) available
+over WAN/internet. In the last case the exchange may be requred to
+queue messages routed to the remote destination if the WAN/internet
+link is down.

+ +

In the terminology I've been using, a cluster is a set of machines
+sharing the same software and configuration, and generally connected
+via an isolated high speed subnet. A federation on the other hand
+consists of distinctly configured machines individually wired
+together. Both clustering and federation could share a common
+protocol for message delivery. This could possibly even be used for
+multicast if it were a simple stateless store-and-forward protocol.
+(Note the "store" in "store-and-forward" can mean both store on disk
+and store in memory.)

+ +

With this model the key distinction between a cluster and a federation
+is that all the nodes in a cluster are managed as a single unit, e.g.
+one place to start/stop/add/remove/etc. Because of this the nodes in a
+cluster have to pass control messages to each other distinct from the
+general message traffic. These control messages need to be isolated
+from the general message traffic (e.g. on their own subnet). This
+could be done using JGroups and OpenAIS for Java and C++ respectively.

+ +

This document doesn't directly address fault tolerance, but it is
+assumed that any node/broker that contains state can be configured to
+have a passive counterpart that supports two methodologies for
+failover. Broker swapout based on virtual IP, or client reconnect to a
+backup IP.

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/ClusteringHA.html b/documentation/content/xdocs/ClusteringHA.html new file mode 100755 index 0000000000..de5abab233 --- /dev/null +++ b/documentation/content/xdocs/ClusteringHA.html @@ -0,0 +1,66 @@ + + + Apache Qpid : ClusteringHA + + + + + + + + + +
+
+ + Apache Qpid : ClusteringHA + +
+
+ This page last changed on Sep 25, 2007 by aconway. +
+ +

Definitions

+ +

The topic is being broken up into three sections:

+ +
    +
  • Federation (a set of distributed exchanges and queues, seperately managed and wired together)
    • +
  • Clustering (a set of distributed exchanges and queues managed as a single entity)
    • +
  • HA / Fault tolarance (the ability for exchanges and queues, clustered, federated, or isolated to replicated important state to a backup (failover partner))
    • +
  • Failover (the ability for a client to reconnect to the failover partner)
    • +
+ + +

Requirements/Use Cases

+ + + + +

Design notes

+ + + +

Historical

+ + + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Configure ACLs.html b/documentation/content/xdocs/Configure ACLs.html new file mode 100755 index 0000000000..31c19b46e2 --- /dev/null +++ b/documentation/content/xdocs/Configure ACLs.html @@ -0,0 +1,40 @@ + + + Apache Qpid : Configure ACLs + + + + + + + + + +
+
+ + Apache Qpid : Configure ACLs + +
+
+ This page last changed on Apr 08, 2008 by ritchiem. +
+ +

Configure ACLs

+ +

This page will be completed shortly with details on how to configure ACLs on the M2.1 broker.

+ +

TBC

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Configure Java Qpid to use a SSL connection..html b/documentation/content/xdocs/Configure Java Qpid to use a SSL connection..html new file mode 100755 index 0000000000..082f53c9b3 --- /dev/null +++ b/documentation/content/xdocs/Configure Java Qpid to use a SSL connection..html @@ -0,0 +1,64 @@ + + + Apache Qpid : Configure Java Qpid to use a SSL connection. + + + + + + + + + +
+
+ + Apache Qpid : Configure Java Qpid to use a SSL connection. + +
+
+ This page last changed on Dec 05, 2007 by ritchiem. +
+ +

Using SSL connection with Qpid Java.

+ +

This section will show how to use SSL to enable secure connections between a Java client and broker.

+ + +

Setup

+ +

Broker Setup

+ +

The broker configuration file (config.xml) needs to be updated to include the SSL keystore location details.

+
Additions required to Connector Section
+
<ssl>
+    <enabled>true</enabled>
+    <sslOnly>true</sslOnly>
+    <keystorePath>/path/to/keystore.ks</keystorePath>
+    <keystorePassword>keystorepass</keystorePassword>
+</ssl>
+
+ +

The sslOnly option is included here for completeness however this will disable the unencrypted port and leave only the SSL port listening for connections.

+ + +

Client Setup

+ +

The best place to start looking is class SSLConfiguration this is provided to the connection during creation however there is currently no example that demonstrates its use.

+ +

Performing the connection.

+ + + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Configure the Broker via config.xml.html b/documentation/content/xdocs/Configure the Broker via config.xml.html new file mode 100644 index 0000000000..5f430942fa --- /dev/null +++ b/documentation/content/xdocs/Configure the Broker via config.xml.html @@ -0,0 +1,51 @@ + + + Apache Qpid : Configure the Broker via config.xml + + + + + + + + + +
+
+ + Apache Qpid : Configure the Broker via config.xml + +
+
+ This page last changed on Apr 08, 2008 by ritchiem. +
+ +

Broker config.xml Overview

+ +

The broker config.xml file which is shipped in the etc directory of any Qpid binary distribution details various options and configuration for the Java Qpid broker implementation.

+ +

In tandem with the virtualhosts.xml file, the config.xml file allows you to control much of the deployment detail for your Qpid broker in a flexible fashion.

+ +

Note that you can pass the config.xml you wish to use for your broker instance to the broker using the -c command line option. In turn, you can specify the paths for the broker password file and virtualhosts.xml files in your config.xml for simplicity.

+ +

For more information about command line configuration options please see Qpid Design - Configuration.

+ +

Qpid Version

+ +

The config format has changed between versions here you can find the configuration details on a per version basis.

+ +

M2 - config.xml
+M2.1 - config.xml

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Configure the Virtual Hosts via virtualhosts.xml.html b/documentation/content/xdocs/Configure the Virtual Hosts via virtualhosts.xml.html new file mode 100755 index 0000000000..219e8d5086 --- /dev/null +++ b/documentation/content/xdocs/Configure the Virtual Hosts via virtualhosts.xml.html @@ -0,0 +1,113 @@ + + + Apache Qpid : Configure the Virtual Hosts via virtualhosts.xml + + + + + + + + + +
+
+ + Apache Qpid : Configure the Virtual Hosts via virtualhosts.xml + +
+
+ This page last changed on Apr 06, 2007 by mmccorma. +
+ +

virtualhosts.xml Overview

+ +

This configuration file contains details of all queues and topics, and associated properties, to be created on broker startup. These details are configured on a per virtual host basis.

+ +

Note that if you do not add details of a queue or topic you intend to use to this file, you must first create a consumer on a queue/topic before you can publish to it using Qpid.

+ +

Thus most application deployments need a virtualhosts.xml file with at least some minimal detail.

+ +

XML Format with Comments

+ +

The virtualhosts.xml which currently ships as part of the Qpid distribution is really targeted at development use, and supports various artifacts commonly used by the Qpid development team.

+ +

As a result, it is reasonably complex. In the example XML below, I have tried to simplify one example virtual host setup which is possibly more useful for new users of Qpid or development teams looking to simply make use of the Qpid broker in their deployment.

+ +

I have also added some inline comments on each section, which should give some extra information on the purpose of the various elements.

+ +
+
+<virtualhosts>
+    <!-- Sets the default virtual host for connections which do not specify a vh -->
+    <default>localhost</default>
+    <!-- Define a virtual host and all it's config -->
+    <virtualhost>
+        <name>localhost</name>
+        <localhost>    
+            <!-- Define the types of additional AMQP exchange available for this vh -->   
+            <!-- Always get amq.direct (for queues) and amq.topic (for topics) by default -->     
+            <exchanges>
+                <!-- Example of declaring an additional exchanges type for developer use only -->
+                <exchange>
+                    <type>direct</type>
+                    <name>test.direct</name>
+                    <durable>true</durable>
+                </exchange>
+            </exchanges>
+             
+            <!-- Define the set of queues to be created at broker startup -->
+            <queues>
+                <!-- The properties configured here will be applied as defaults to all -->
+                <!-- queues subsequently defined unless explicitly overridden -->
+                <exchange>amq.direct</exchange>
+                <!-- Set threshold values for queue monitor alerting to log --> 
+                <maximumQueueDepth>4235264</maximumQueueDepth>  <!-- 4Mb -->
+                <maximumMessageSize>2117632</maximumMessageSize> <!-- 2Mb -->
+                <maximumMessageAge>600000</maximumMessageAge>  <!-- 10 mins -->
+
+                <!-- Define a queue with all default settings -->   
+                <queue>
+                    <name>ping</name>
+                </queue>
+                <!-- Example definitions of queues with overriden settings -->
+                <queue>
+                    <name>test-queue</name>
+                    <test-queue>
+                        <exchange>test.direct</exchange>
+                        <durable>true</durable>
+                    </test-queue>
+                </queue>
+                <queue>
+                    <name>test-ping</name>
+                    <test-ping>
+                        <exchange>test.direct</exchange>
+                    </test-ping>
+                </queue>
+            </queues>
+        </localhost>
+    </virtualhost>
+</virtualhosts>
+
+
+ + +

Using your own virtualhosts.xml

+ +

Note that the config.xml file shipped as an example (or developer default) in the Qpid distribution contains an element which defines the path to the virtualhosts.xml.

+ +

When using your own virtualhosts.xml you must edit this path to point at the location of your file.

+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Configuring Qpid Management Console.html b/documentation/content/xdocs/Configuring Qpid Management Console.html new file mode 100755 index 0000000000..e59215f8ba --- /dev/null +++ b/documentation/content/xdocs/Configuring Qpid Management Console.html @@ -0,0 +1,105 @@ + + + Apache Qpid : Configuring Qpid Management Console + + + + + + + + + +
+
+ + Apache Qpid : Configuring Qpid Management Console + +
+
+ This page last changed on Jun 29, 2007 by ritchiem. +
+ +

Configuring Qpid Management Console

+ +

QPID has a management interface that exposes . By default the management interface is enabled but it can also be disabled by modifying the management element in config.xml.

+ +

When starting the broker, the following system properties need to be set by setting the environment variable QPID_OPTS:

+
+

QPID_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8999 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false"

+
+ +

Note that you should only use these settings for non-production systems. For production deployments you should use authentication !

+ +

You can find out more about the features exposed by the Qpid JMS interfaces here.

+ +

Using Eclipse RCP

+ + +

Installing the Qpid Management Console (eclipse RCP)

+ +

Unzip the management eclipse plugin zip for windows in a dir (eg C:/). A dir with name qpidmc (eg C:/qpidmc) will get created.

+ +

To run the RCP from command prompt, set the environment variable QPIDMC_HOME to installation dir (eg. QPIDMC_HOME=C:/qpidmc)  and include $QPIDMC_HOME/bin in your PATH.

+ +

Running the Qpid Management Console (eclipse RCP)

+ +

To run this application on windows, run any of these scripts-

+ +

qpidmc.bat (windows command prompt)

+ +

qpidmc.sh  (cygwin) 

+ +

For running on unix, use the scritps for particular windowing system
+qpidmc_<windowing system>.sh (eg. qpidmc_motif.sh)

+ +

Using the Qpid Management Console (eclipse RCP)

+ +

Please see [attachment |^Qpid_Management_Console.doc] for using this Eclipse RCP.  Attchment contains some of the screenshots of Qpid Management Console (Eclipse RCP) .

+ +

Using JConsole

+ +

JConsole is a management tool that comes with the Java Runtime Environment and provides a very simple view of managed beans. It requires no special configuration to be used with QPID.

+ +

To attach to a running broker simply enter the host and port details on the JConsole connect dialog. The port should be the same as the one specified in the system property com.sun.management.jmxremote.port.

+ +

Once you are connected expand the tree nodes marked "org.apache".

+ +

Please see attachment for some of the [screenshots|^Qpid_using_jconsole.doc] of using jconsole for Qpid.

+ +

Using HermesJMS

+ +

HermesJMS also offers integration with the Qpid management interfaces. You can get instructions and more information from http://wiki.apache.org/qpid/HermesJMS.

+ +

Using MC4J

+ +

MC4J is an alternative management tool. It provide a richer "dashboard" that can customise the raw MBeans.

+ +

Installation

+ +
    +
  • First download and install MC4J for your platform. Version 1.2 beta 9 is the latest version that has been tested.
    • +
  • Copy the directory blaze/java/management/mc4j into the directory <MC4J-Installation>/dashboards
    • +
+ + +

Configuration

+ +

You should create a connection the JVM to be managed. Using the Management->Create Server Connection menu option. The connection URL should be of the form: service:jmx:rmi:///jndi/rmi://localhost:8999/jmxrmi making the appropriate host and post changes.

+ +

Operation

+ +

You can view tabular summaries of the queues, exchanges and connections using the Global Dashboards->QPID tree view. To drill down on individual beans you can right click on the bean. This will show any available graphs too.

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Connection URL Format.html b/documentation/content/xdocs/Connection URL Format.html new file mode 100755 index 0000000000..e0223b0626 --- /dev/null +++ b/documentation/content/xdocs/Connection URL Format.html @@ -0,0 +1,167 @@ + + + Apache Qpid : Connection URL Format + + + + + + + + + +
+
+ + Apache Qpid : Connection URL Format + +
+
+ This page last changed on Apr 02, 2008 by asimon. +
+ +
+
amqp://[<user>:<pass>@][<clientid>]<virtualhost>[?<option>='<value>'[&<option>='<value>']]
+
+
+ +

The connection url defines the values that are common across the cluster of brokers. The virtual host is second in the list as the AMQP specification demands that it start with a '/' otherwise it be more readable to be swapped with clientid. There is currently only one required option and that is the brokerlist option. In addition the following options are recognised.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
OptionDefaultDescription
sslfalseSet the default for all connections. This can be overridden by the individual broker url.
brokerlistsee belowThe list of brokers to use for this connection
failoversee belowThe type of failover method to use with the broker list.
cyclecount0 The number of times to loop through the list of available brokers before failure.
+ +

Brokerlist option

+
+
brokerlist='<broker url>[;<broker url>]'
+
+
+ +

The broker list defines the various brokers that can be used for this connection. A minimum of one broker url is required additional URLs are semi-colon(';') delimited.

+ +

Broker URL format

+
+
<transport>://<host>[:<port>][?<option>='<value>'[&<option>='<value>']]
+
+
+ +

There are currently quite a few default values that can be assumed. This was done so that the current client examples would not have to be re-written. The result is if there is no transport, 'tcp' is assumed and the default AMQP port of 5672 is used if no port is specified.

+ + + + + + + + + + + +
Transport
tcp
vm
+ +

Currently only 'tcp' and 'vm' transports are supported. Each broker can take have additional options that are specific to that broker. The following are currently implemented options. To add support for further transports the ''client.transportTransportConnection'' class needs updating along with the parsing to handle the transport.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
OptionDefaultDescription
retries1 The number of times to retry connection to this Broker
sslfalseUse ssl on the connection
connecttimeout30000How long in (milliseconds) to wait for the connection to succeed
connectdelaynoneHow long in (milliseconds) to wait before attempting to reconnect
+ + +

Brokerlist failover option

+
+
failover='<method>[?<options>]'
+
+
+ +

This option controls how failover occurs when presented with a list of brokers. There are only two methods currently implemented but interface qpid.jms.failover.FailoverMethod can be used for defining further methods.

+ +

Currently implemented failover methods.

+ + + + + + + + + + + + + + +
MethodDescription
singlebrokerThis will only use the first broker in the list.
roundrobinThis method tries each broker in turn.
+ +

The current defaults are naturally to use the 'singlebroker' when only one broker is present and the 'roundrobin' method with multiple brokers. The '''method''' value in the URL may also be any valid class on the classpath that implements the FailoverMethod interface.

+ +

Sample URLs

+
+
amqp:///test?brokerlist='localhost'
+amqp:///test?brokerlist='tcp://anotherhost:5684?retries='10''
+amqp://guest:guest@/test?brokerlist='vm://:1;vm://:2'&failover='roundrobin'
+amqp://guest:guest@/test?brokerlist='vm://:1;vm://:2'&cyclecount='20'
+amqp://guest:guest@client/test?ssl='true'&brokerlist='tcp://localhost;tcp://redundant-server:5673?ssl='false''&failover='roundrobin'
+
+
+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Cpp Client Java Interop Issues.html b/documentation/content/xdocs/Cpp Client Java Interop Issues.html new file mode 100755 index 0000000000..1f81de2873 --- /dev/null +++ b/documentation/content/xdocs/Cpp Client Java Interop Issues.html @@ -0,0 +1,71 @@ + + + Apache Qpid : Cpp Client Java Interop Issues + + + + + + + + + +
+
+ + Apache Qpid : Cpp Client Java Interop Issues + +
+
+ This page last changed on Feb 15, 2007 by mmccorma. +
+ +

Issues affecting C++ client/Java broker/Java client interop build 6th Feb:

+ +

Open Issues

+ + + + +
    +
  • Non-Apache JIRA - Problem with BDBStore queue recreation at startup - details: +
    +
    Restarting our application, I sometimes get a "Protocol Error" exception and the following
+message appearing in the broker log. This is even after restarting the broker when there
+are absolutely no connections. 
+RECV: Frame[channel=1; ChannelClose: replyCode=405; replyText=Cannot declare queue, as
+exclusive queue with same name declared on another connection [error code 405]; classId=50;
+methodId=10] 
+
+I deleted the $QPID_WORK/<virtual-host>-store directory and I was able to restart. 
+
+Also, in the application code, the queue is created as shared (single param constructor) so
+not sure why the broker thinks that it is exclusive? 
+
    +
    • +
+ + +

Resolved Issues

+ + + + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/CppApiGuide.html b/documentation/content/xdocs/CppApiGuide.html new file mode 100755 index 0000000000..5c01c7a3f2 --- /dev/null +++ b/documentation/content/xdocs/CppApiGuide.html @@ -0,0 +1,82 @@ + + + Apache Qpid : CppApiGuide + + + + + + + + + +
+
+ + Apache Qpid : CppApiGuide + +
+
+ This page last changed on Sep 26, 2007 by gsim@redhat.com. +
+ +

C++ public API guidelines.

+ +

These guidelines are for the public client API to be released in qpid 1.0. The "plugin" API exposed for bdbstore should eventually follow these guidelines but it can be deferred.

+ +

Public header files

+ +

Public headers under: qpid/cpp/src/include 

+ +

Non-unit client tests  should be built with -I include and without -I . so that missing public headers can be quickly identified.

+ +

 Only src/include headers are installed with package qpidc-devel. Package qpidd-devel should only install src/include headers, but for 1.0 it may still install private headers.

+ + +

PIMPL idiom

+ + +

Value classes needed by the user (e.g. framing data types, message content) are exposed as normal classes in public headers.

+ +

Service classes (e.g. Session, Connection etc) use the pimpl idiom for  compatibility isolation. See http://en.wikipedia.org/wiki/Pimpl.

+ + +

Thread safety

+ +

I believe making the session thread safe will make it simpler to use in various circumstances (some of which may be unforeseen). I don't think it necessarily adds significant overhead (though this is something we can verify).

+ + +
+ Comments: +
+ + + + + +
+ +

= Namespaces in Client Applications =

+ +

Currently, a client application needs the following namespaces:

+ +

using namespace qpid::client;
+using namespace qpid::framing;

+ +

Why should someone writing a client application need to know about the framing namespace? And is 'framing' really the best name to describe this namespace?

 +
+ + Posted by jonathan.robie@redhat.com at Sep 20, 2007 06:58 +
+
+
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/CppEventChannelIo.html b/documentation/content/xdocs/CppEventChannelIo.html new file mode 100755 index 0000000000..ec38687b43 --- /dev/null +++ b/documentation/content/xdocs/CppEventChannelIo.html @@ -0,0 +1,167 @@ + + + Apache Qpid : CppEventChannelIo + + + + + + + + + +
+
+ + Apache Qpid : CppEventChannelIo + +
+
+ This page last changed on Nov 06, 2006 by aconway. +
+ +

Event channel IO abstraction.

+ +

Goals: provide an IO abstraction layer that can be efficiently implemented using differente techniques:

+ +
    +
  • select/poll/epoll
    • +
  • aio_
    • +
  • ec_ new linux event channel.
    • +
  • shared mem, IPC etc.
    • +
+ + +

The event channel is the central IO absctraction.

+ +

Async requests are posted to the channel as Events. When the request is complete it is returned from getEvent() with the data filled in.

+ +

We provide synchronous APIs to wrap post(event), wait for getEvent(). On posix these APIs are actually implemented using user-level context swithching so we get a simple programing model with minimal blocking and kernel context switching.

+ +

Note: this means that code before and after an apparently synchronous call ''may execute in different threads''. Don't use thread-local
+storage. The term "task" will denote the user-level execution context and we'll provide "task-locak storage" that is carried with the user
+context if we need it.

+ +

We can provide some simple in-process synchronization via the event channel to allow use level tasks to block on application events.

+ +

Core concepts:

+ +

EventChannel:

+ +
    +
  • Manages thread pool.
    • +
+ + +
    +
  • Worker threads loop getting and processing events.
    • +
+ + +
    +
  • Async requests: post request event, it will be processed when complete.
    • +
+ + +
    +
  • Notification: Threads can block on a notification event to be woken when some other thread posts that event.
    • +
+ + +

Task:

+ +
    +
  • like lightweight thread
    • +
+ + +
    +
  • ucontext APIs for user-level context switch.
    • +
+ + +

Linux ec_ + ucontext implementation:

+ +
    +
  • EventChannel is thin facade over native ec_ APIs.
    • +
+ + +
    +
  • Tasks are scheduled onto threads.
    • +
+ + +
    +
  • ideally our threads ''never block'' (but they can be preempted)
    • +
+ + +
    +
  • when a thread hits a blocking point it suspends the current task and swaps to a ready task.
    • +
+ + +
    +
  • when the suspended task is unblocked (e.g. async IO completes) it becomes ready and will be picked up by another thread.
    • +
+ + +

Linux epoll + ucontext:

+ +
    +
  • Prove ucontext ideas.
    • +
+ + +
    +
  • Use traditional polling inside EventChannel.
    • +
+ + +

APR portable impl: only need client support - simple blocking socket calls.

+ +

Computing thread pool size:

+ +
    +
  • Initial size based on availabe CPU paralleism
    • +
+ + +
    +
  • On linux /proc/cpuinfo? Any portable options.
    • +
+ + +
    +
  • Thread pool grows automatically to avoid deadlock.
    • +
+ + +

ThreadPool: Size should stay close to actuall hardware paralellism + some delta due to pre-empted threads and thread-blocking
+synchronization calls required in the event channel implementation itself.

+ +

Questions:

+ +
    +
  • Does the thread pool need to shrink to reclaim resources?
    • +
+ + +
    +
  • Is there a risk of unbounded growth? How to avoid without deadlock?
    • +
+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/CppHandlerChains.html b/documentation/content/xdocs/CppHandlerChains.html new file mode 100755 index 0000000000..7896cc8feb --- /dev/null +++ b/documentation/content/xdocs/CppHandlerChains.html @@ -0,0 +1,76 @@ + + + Apache Qpid : CppHandlerChains + + + + + + + + + +
+
+ + Apache Qpid : CppHandlerChains + +
+
+ This page last changed on Sep 20, 2007 by aconway. +
+ +

The C++ broker uses handler chains to break complex processing into individual pieces.

+ +
    +
  • Each session has its own set of FrameHandler chains.
    • +
  • Frames from the network are delivered to the first handler in the chain.
    • +
  • Handlers do something with a frame, then pass it to the next handler.
    • +
  • Handlers may "filter" frames by not passing some frames to the next handler.
    • +
+ + +

Current status (2002/9/20)

+ +

Each chain starts with a SessionHandler. It handles L2 (session open, close etc.) and passes other frames to the next handler.

+ +

L3/L4 frames are handled by the SemanticHandler.

+ +

For clustering, a ClusterHandler is inserted at the start of the chain. It replicates frames to a backup broker so the backup can handle failover. It then passes frames on to the normal session handlers.

+ +

Approach for multi-frame segments

+ +
    +
  • The frame handler chain continues to handle individual frames.
    • +
  • Each handler uses a FrameSet to accumulate its frames.
    • +
  • Frame no longer contains a Body, moved to FrameSet +
    +
    class FrameSet { // sketch
+ void add(const Frame& frame); // True if 
+ const AMQMethodBody* getMethod(); // 0 means not complete.
+ const AMQHeaderBody* getHeader();
+ const AMQContentBody* getContent(); 
+};
    +
    +

    Note: All the visitor/dispatch classes using AMQFrame need to be reworked. Dispatch will always be based on an AMQMethodBody, not a frame.

    • +
+ + +

Rationale:

+ +

''Frame rather than Segment/FrameSet handlers'': Allows most flexibility to compose or not compose frames into segments & FrameSets. For example a cluster handler needs to replicate frame-by-frame, so we don't want to compose the full segment up front. Since the FrameSet class provides the composition logic, this is specified only once and easy to use in frame handlers.

+ +

''No Segment class'': A segment by itself is not very useful. A non-content method is just a FrameSet containing a single method segment. For content bearing methods are a frameset with headers & content. There's little value for a stand alone segment class.

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/CppStyleGuide.html b/documentation/content/xdocs/CppStyleGuide.html new file mode 100755 index 0000000000..92f21cd503 --- /dev/null +++ b/documentation/content/xdocs/CppStyleGuide.html @@ -0,0 +1,86 @@ + + + Apache Qpid : CppStyleGuide + + + + + + + + + +
+
+ + Apache Qpid : CppStyleGuide + +
+
+ This page last changed on Apr 24, 2007 by aconway. +
+ +

Qpid C++ style guide

+ +

Qpid C++ follows this guide: http://geosoft.no/development/cppstyle.html

+ +

With the following amendments:

+ +
    +
  • Rule 34: Qpid source files have .h and .cpp extensions.
    • +
  • Rule 71: Qpid uses 4 space indent, not 2. No tabs.
    • +
  • Rule 75, 81: Qpid allows (but does not require) else/catch to be on same line as preceeding }
    • +
  • Rule 11: Qpid does not add an underscore to member variable names.
    • +
+ + +

And the following additional rules:

+ +
    +
  • Rule q1: Unlike other blocks, the contents of namespace blocks are not indented to prevent excessive line splitting, and multiple namespaces may be opened or closed on a single line. For example: +
    +
    namespace qpid { namespace common {
+
+class SomeClass {
+  void foo();
+};
+
+}} // namespace qpid::common
    +
    • +
+ + + + +

Debate and changes

+ +

The discussion on qpid-dev did raise debate about some points of the style guide. The exceptions and new rules above reflect:

+
    +
  • Points that were agreed on the list.
    • +
  • De-facto style of the codebase as it stands today.
    • +
+ + +

Anyone who feels strongly about further modifications to the style guide should:

+
    +
  1. Raise the issue on qpid-dev.
    2. +
  2. Get consensus among the active qpid C++ developers for the change.
    3. +
  3. Reformat the entire qpid codebase to conform to the change.
    4. +
+ + +

If you are not willing to do step 3 then don't bother raising the issue.

+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/CppTips.html b/documentation/content/xdocs/CppTips.html new file mode 100755 index 0000000000..2dddad2409 --- /dev/null +++ b/documentation/content/xdocs/CppTips.html @@ -0,0 +1,55 @@ + + + Apache Qpid : CppTips + + + + + + + + + +
+
+ + Apache Qpid : CppTips + +
+
+ This page last changed on Mar 28, 2007 by aconway. +
+ +

Some advice on makefiles and build system

+
    +
  • SingleMakefile
    • +
+ + +

This is a collection of coding guidelines, some specific to Qpid, some just good practice in C++.

+ + + + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Developer Pages.html b/documentation/content/xdocs/Developer Pages.html new file mode 100755 index 0000000000..34b210b9e3 --- /dev/null +++ b/documentation/content/xdocs/Developer Pages.html @@ -0,0 +1,82 @@ + + + Apache Qpid : Developer Pages + + + + + + + + + +
+
+ + Apache Qpid : Developer Pages + +
+
+ This page last changed on Apr 18, 2008 by godfrer. +
+ +

Developer Pages

+ +

Implementations, Style guides and Tools

+ +

Follow the links below to view documentation about the Java & C++ brokers, client implementations and other useful project information. Our project documentation is currently being expanded so check back for updates !

+ + + + +

Design notes

+ + + +

Weekly Developer Meeting Minutes

+ + + + +
+
+ Attachments: +
+ +
+ + merege_test_output.txt (application/octet-stream) +
+
+ +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Developer Pages_attachments/merege_test_output.txt b/documentation/content/xdocs/Developer Pages_attachments/merege_test_output.txt new file mode 100755 index 0000000000..2ff820ea55 --- /dev/null +++ b/documentation/content/xdocs/Developer Pages_attachments/merege_test_output.txt @@ -0,0 +1,470 @@ +[INFO] Scanning for projects... +[INFO] Reactor build order: +[INFO] Qpid +[INFO] Qpid Common Utilities +[INFO] Qpid Broker +[INFO] junit-toolkit +[INFO] Qpid Client +[INFO] Qpid Plugins +[INFO] junit-toolkit-maven-plugin +[INFO] Qpid System Tests +[INFO] Qpid Performance Tests +[INFO] Qpid Integration Tests +[INFO] Qpid Management +[INFO] Qpid Example +[INFO] Qpid Client for Java 1.4 +[INFO] ---------------------------------------------------------------------------- +[INFO] Building Qpid +[INFO] task-segment: [test] +[INFO] ---------------------------------------------------------------------------- +[INFO] No goals needed for project - skipping +[INFO] ---------------------------------------------------------------------------- +[INFO] Building Qpid Common Utilities +[INFO] task-segment: [test] +[INFO] ---------------------------------------------------------------------------- +[INFO] [antrun:run {execution: protocol-version}] +[INFO] Executing tasks + [echo] "C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\common\target/generated-sources/gentools" + +compile_generator: + +compile: + +generate: + [java] XML files: [C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\specs/amqp.0-8.xml, C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\specs/amqp.0-9.xml] + [java] "C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\specs/amqp.0-8.xml": Found version 8-0. + [java] "C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\specs/amqp.0-9.xml": Found version 0-9. + [java] Looking for template files in directory: C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\common\templates\model + [java] Looking for version specific template files in directory: C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\common\templates\model\version + [java] model template file(s): + [java] C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\common\templates\model\ClientMethodDispatcherInterface.vm + [java] model template file(s): + [java] C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\common\templates\model\MethodDispatcherInterface.vm + [java] model template file(s): + [java] C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\common\templates\model\MethodRegistryClass.vm + [java] model template file(s): + [java] C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\common\templates\model\ProtocolVersionListClass.vm + [java] model template file(s): + [java] C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\common\templates\model\ServerMethodDispatcherInterface.vm + [java] model template file(s): + [java] C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\common\templates\model\version\AmqpConstantsClass.vm + [java] model template file(s): + [java] C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\common\templates\model\version\ClientMethodDispatcherInterface.vm + [java] model template file(s): + [java] C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\common\templates\model\version\MethodDispatcherInterface.vm + [java] model template file(s): + [java] C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\common\templates\model\version\MethodRegistryClass.vm + [java] model template file(s): + [java] C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\common\templates\model\version\ServerMethodDispatcherInterface.vm + [java] Looking for template files in directory: C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\common\templates\class + [java] Looking for version specific template files in directory: C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\common\templates\class\version + [java] Looking for template files in directory: C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\common\templates\method + [java] Looking for version specific template files in directory: C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\common\templates\method\version + [java] method template file(s): + [java] C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\common\templates\method\MethodBodyInterface.vm + [java] method template file(s): + [java] C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\common\templates\method\version\MethodBodyClass.vm + [java] Looking for template files in directory: C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\common\templates\field + [java] Looking for version specific template files in directory: C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\common\templates\field\version + [java] Generation directory: C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\common\target\generated-sources\gentools\org\apache\qpid\framing + [java] Files generated: 0 + [java] Done. +[INFO] Executed tasks +[INFO] Registering compile source root C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\common\target\generated-sources\gentools +[INFO] [jython:jython {execution: jython}] +[INFO] [resources:resources] +[INFO] Using default encoding to copy filtered resources. +[INFO] [compiler:compile] +Compiling 325 source files to C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\common\target\classes +[INFO] [antrun:run {execution: version_properties}] +[INFO] Executing tasks +[propertyfile] Updating property file: C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\common\target\classes\qpidversion.properties +[INFO] Executed tasks +[INFO] [resources:testResources] +[INFO] Using default encoding to copy filtered resources. +[INFO] [compiler:testCompile] +[INFO] Nothing to compile - all classes are up to date +[INFO] [surefire:test] +[INFO] Surefire report directory: C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\common\target\surefire-reports + +------------------------------------------------------- + T E S T S +------------------------------------------------------- +Running org.apache.qpid.pool.PoolingFilterTest +log4j:WARN No appenders could be found for logger (org.apache.qpid.pool.PoolingFilter). +log4j:WARN Please initialize the log4j system properly. +Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.125 sec +Running org.apache.qpid.framing.BasicContentHeaderPropertiesTest +Tests run: 18, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.156 sec +Running org.apache.qpid.util.CommandLineParserTest +Tests run: 22, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec +Running org.apache.qpid.framing.AMQShortStringTest +Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec +Running org.apache.qpid.util.SerialTest +Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec +Running org.apache.qpid.session.TestSession +Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec +Running org.apache.qpidity.transport.ConnectionTest +Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.594 sec +Running org.apache.qpid.framing.PropertyFieldTableTest +Tests run: 23, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.093 sec + +Results : +Tests run: 71, Failures: 0, Errors: 0, Skipped: 0 + +[INFO] ---------------------------------------------------------------------------- +[INFO] Building Qpid Broker +[INFO] task-segment: [test] +[INFO] ---------------------------------------------------------------------------- +[WARNING] While downloading javacc:javacc:3.2 + This artifact has been relocated to net.java.dev.javacc:javacc:3.2. + + +[INFO] [javacc:javacc {execution: default}] +[INFO] Nothing to process - all grammars are up to date +[INFO] [resources:resources] +[INFO] Using default encoding to copy filtered resources. +[INFO] [compiler:compile] +[INFO] Nothing to compile - all classes are up to date +[INFO] [antrun:run {execution: version_properties}] +[INFO] Executing tasks +[propertyfile] Updating property file: C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\broker\target\classes\qpidversion.properties +[INFO] Executed tasks +[INFO] [resources:testResources] +[INFO] Using default encoding to copy filtered resources. +[INFO] [compiler:testCompile] +[INFO] Nothing to compile - all classes are up to date +[INFO] [surefire:test] +[INFO] Surefire report directory: C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\broker\target\surefire-reports +main 2008-04-17 15:48:19,460 WARN [security.auth.sasl.UsernamePasswordInitialiser] we need a server that will correctly convert the incomming plain text for comparison to file. +main 2008-04-17 15:48:20,320 WARN [server.security.access.ACLManager] No ACL Plugin specified. Using default ACL Plugin 'AllowAll' for VirtualHost:'test' + +------------------------------------------------------- + T E S T S +------------------------------------------------------- +Running org.apache.qpid.server.util.LoggingProxyTest +Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec +Running org.apache.qpid.server.SelectorParserTest +Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.063 sec +Running org.apache.qpid.server.configuration.TestPropertyUtils +Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec +Running org.apache.qpid.server.exchange.ExchangeMBeanTest +Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.125 sec +Running org.apache.qpid.server.queue.AMQQueueAlertTest +Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.312 sec +Running org.apache.qpid.server.exchange.HeadersBindingTest +Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec +Running org.apache.qpid.server.queue.AMQQueueMBeanTest +Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.079 sec +Running org.apache.qpid.server.protocol.TestIoSession +Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec +Running org.apache.qpid.server.store.TestableMemoryMessageStore +Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec +Running org.apache.qpid.server.exchange.DestWildExchangeTest +Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec +Running org.apache.qpid.server.protocol.TestMinaProtocolSession +Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec + +Results : +Tests run: 53, Failures: 0, Errors: 0, Skipped: 0 + +[INFO] [antrun:run {execution: python_test}] +[INFO] Executing tasks + +run-tests: + [echo] Starting Broker with command + [java] main 2008-04-17 15:48:22,789 DEBUG [apache.qpid.common.QpidProperties] Dumping QpidProperties + [java] main 2008-04-17 15:48:22,789 DEBUG [apache.qpid.common.QpidProperties] Property: qpid.version Value: 1.0-incubating-M3-SNAPSHOT + [java] main 2008-04-17 15:48:22,789 DEBUG [apache.qpid.common.QpidProperties] Property: qpid.svnversion Value: 649054:649132 + [java] main 2008-04-17 15:48:22,789 DEBUG [apache.qpid.common.QpidProperties] Property: qpid.name Value: Qpid Broker + [java] main 2008-04-17 15:48:22,789 DEBUG [apache.qpid.common.QpidProperties] End of property dump + [java] Qpid Broker - 1.0-incubating-M3-SNAPSHOT build: 649054:649132 (AMQP version(s) [major.minor]: 8-0, 0-9) + [java] Using configuration file C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\broker\etc\config.xml + [java] Configuring logger using configuration file C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\broker\etc\log4j.xml + [java] 2008-04-17 15:48:23,789 WARN [main] management.AMQUserManagementMBean (AMQUserManagementMBean.java:387) - Access rights contains user 'admin' but there is no authentication data for that user + [java] 2008-04-17 15:48:23,789 WARN [main] management.AMQUserManagementMBean (AMQUserManagementMBean.java:387) - Access rights contains user 'user' but there is no authentication data for that user + [java] 2008-04-17 15:48:24,570 WARN [main] management.JMXManagedObjectRegistry (JMXManagedObjectRegistry.java:153) - JMX: Started JMXConnector server on port '2111' with security disabled + [java] 2008-04-17 15:48:24,679 WARN [main] access.ACLManager (ACLManager.java:52) - No ACL Plugin specified. Using default ACL Plugin 'AllowAll' for VirtualHost:'localhost' + [java] 2008-04-17 15:48:24,711 WARN [main] access.ACLManager (ACLManager.java:52) - No ACL Plugin specified. Using default ACL Plugin 'AllowAll' for VirtualHost:'development' + [java] 2008-04-17 15:48:24,726 WARN [main] access.ACLManager (ACLManager.java:52) - No ACL Plugin specified. Using default ACL Plugin 'AllowAll' for VirtualHost:'test' + [java] 2008-04-17 15:48:24,726 INFO [main] server.Main (Main.java:267) - Starting Qpid Broker 1.0-incubating-M3-SNAPSHOT build: 649054:649132 + [java] 2008-04-17 15:48:24,929 WARN [main] transport.ConnectorConfiguration (ConnectorConfiguration.java:110) - Using Mina IO Processing + [java] 2008-04-17 15:48:25,039 INFO [main] server.Main (Main.java:420) - Qpid.AMQP listening on non-SSL address 0.0.0.0/0.0.0.0:2110 + [java] 2008-04-17 15:48:25,039 INFO [main] server.Main (Main.java:441) - Qpid Broker Ready :1.0-incubating-M3-SNAPSHOT build: 649054:649132 + [java] Started Proccess: python run-tests -v -I java_failing.txt -b localhost:2110 -s ../specs/amqp.0-9.no-wip.xml + [java] [ERR]Traceback (most recent call last): + [java] [ERR] File "run-tests", line 32, in + [java] [ERR] if not testrunner.run(): sys.exit(1) + [java] [ERR] File "/cygdrive/c/work/qpid/thegreatmerge/thegreatmerge-working/qpid/python/qpid/testlib.py", line 176, in run + [java] [ERR] self._parseargs(args) + [java] [ERR] File "/cygdrive/c/work/qpid/thegreatmerge/thegreatmerge-working/qpid/python/qpid/testlib.py", line 129, in _parseargs + [java] [ERR] if opt in ("-I", "--ignore-file"): self.ignoreFile(value) + [java] [ERR] File "/cygdrive/c/work/qpid/thegreatmerge/thegreatmerge-working/qpid/python/qpid/testlib.py", line 96, in ignoreFile + [java] [ERR] f = file(filename) + [java] [ERR]IOError: [Errno 2] No such file or directory: 'java_failing.txt' + [java] Waiting for process to exit: python run-tests -v -I java_failing.txt -b localhost:2110 -s ../specs/amqp.0-9.no-wip.xml + [java] Done Proccess: python run-tests -v -I java_failing.txt -b localhost:2110 -s ../specs/amqp.0-9.no-wip.xml +[INFO] Executed tasks +[INFO] ---------------------------------------------------------------------------- +[INFO] Building junit-toolkit +[INFO] task-segment: [test] +[INFO] ---------------------------------------------------------------------------- +[INFO] [resources:resources] +[INFO] Using default encoding to copy filtered resources. +[INFO] [compiler:compile] +[INFO] Nothing to compile - all classes are up to date +[INFO] [resources:testResources] +[INFO] Using default encoding to copy filtered resources. +[INFO] [compiler:testCompile] +[INFO] No sources to compile +[INFO] [surefire:test] +[INFO] Surefire report directory: C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\junit-toolkit\target\surefire-reports + +------------------------------------------------------- + T E S T S +------------------------------------------------------- +There are no tests to run. + +Results : +Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 + +[INFO] ---------------------------------------------------------------------------- +[INFO] Building Qpid Client +[INFO] task-segment: [test] +[INFO] ---------------------------------------------------------------------------- +[INFO] Ignoring available plugin update: 2.4 as it requires Maven version 2.0.8 +[INFO] Ignoring available plugin update: 2.4-SNAPSHOT as it requires Maven version 2.0.8 +[INFO] [javacc:javacc {execution: default}] +[INFO] Nothing to process - all grammars are up to date +[INFO] [resources:resources] +[INFO] Using default encoding to copy filtered resources. +[INFO] [compiler:compile] +[INFO] Nothing to compile - all classes are up to date +[INFO] [antrun:run {execution: version_properties}] +[INFO] Executing tasks +[propertyfile] Updating property file: C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\client\target\classes\qpidversion.properties +[INFO] Executed tasks +[INFO] [resources:testResources] +[INFO] Using default encoding to copy filtered resources. +[INFO] [compiler:testCompile] +[INFO] Nothing to compile - all classes are up to date +[INFO] [surefire:test] +[INFO] Surefire report directory: C:\work\qpid\thegreatmerge\thegreatmerge-working\qpid\java\client\target\surefire-reports + +------------------------------------------------------- + T E S T S +------------------------------------------------------- +Running org.apache.qpid.test.unit.topic.TopicSessionTest +log4j:WARN No appenders could be found for logger (org.apache.qpid.testutil.QpidTestCase). +log4j:WARN Please initialize the log4j system properly. +Tests run: 8, Failures: 0, Errors: 8, Skipped: 0, Time elapsed: 1.828 sec <<< FAILURE! +Running org.apache.qpid.test.unit.client.connectionurl.ConnectionURLTest +Tests run: 24, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.063 sec +Running org.apache.qpid.client.AMQQueueDeferredOrderingTest +Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.015 sec <<< FAILURE! +Running org.apache.qpid.test.unit.basic.MultipleConnectionTest +Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.015 sec <<< FAILURE! +Running org.apache.qpid.test.unit.client.message.MapMessageTest +Tests run: 18, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec +Running org.apache.qpid.test.unit.transacted.TransactedTest +java.lang.NullPointerException + at org.apache.qpid.client.handler.ClientMethodDispatcherImpl.newMethodDispatcher(ClientMethodDispatcherImpl.java:86) + at org.apache.qpid.client.protocol.AMQProtocolSession.setStateManager(AMQProtocolSession.java:171) + at org.apache.qpid.client.protocol.AMQProtocolHandler.setStateManager(AMQProtocolHandler.java:750) + at org.apache.qpid.client.AMQConnection.(AMQConnection.java:451) + at org.apache.qpid.client.AMQConnection.(AMQConnection.java:281) + at org.apache.qpid.testutil.QpidTestCase.getConnection(QpidTestCase.java:339) + at org.apache.qpid.test.unit.transacted.TransactedTest.setUp(TransactedTest.java:65) + at junit.framework.TestCase.runBare(TestCase.java:125) + at org.apache.qpid.testutil.QpidTestCase.runBare(QpidTestCase.java:131) + at junit.framework.TestResult$1.protect(TestResult.java:106) + at junit.framework.TestResult.runProtected(TestResult.java:124) + at junit.framework.TestResult.run(TestResult.java:109) + at junit.framework.TestCase.run(TestCase.java:118) + at org.apache.qpid.testutil.QpidTestCase.run(QpidTestCase.java:157) + at junit.framework.TestSuite.runTest(TestSuite.java:208) + at junit.framework.TestSuite.run(TestSuite.java:203) + at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) + at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) + at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) + at java.lang.reflect.Method.invoke(Method.java:597) + at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210) + at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135) + at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122) + at org.apache.maven.surefire.Surefire.run(Surefire.java:129) + at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) + at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) + at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) + at java.lang.reflect.Method.invoke(Method.java:597) + at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225) + at org.apache.maven.surefire.booter.SurefireBooter.run(SurefireBooter.java:139) + at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:376) + at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) + at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) + at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) + at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) + at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) + at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) + at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) + at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) + at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) + at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) + at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) + at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) + at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) + at java.lang.reflect.Method.invoke(Method.java:597) + at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) + at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) + at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) + at org.codehaus.classworlds.Launcher.main(Launcher.java:375) +java.lang.NullPointerException + at org.apache.qpid.client.handler.ClientMethodDispatcherImpl.newMethodDispatcher(ClientMethodDispatcherImpl.java:86) + at org.apache.qpid.client.protocol.AMQProtocolSession.setStateManager(AMQProtocolSession.java:171) + at org.apache.qpid.client.protocol.AMQProtocolHandler.setStateManager(AMQProtocolHandler.java:750) + at org.apache.qpid.client.AMQConnection.(AMQConnection.java:451) + at org.apache.qpid.client.AMQConnection.(AMQConnection.java:281) + at org.apache.qpid.testutil.QpidTestCase.getConnection(QpidTestCase.java:339) + at org.apache.qpid.test.unit.transacted.TransactedTest.setUp(TransactedTest.java:65) + at junit.framework.TestCase.runBare(TestCase.java:125) + at org.apache.qpid.testutil.QpidTestCase.runBare(QpidTestCase.java:131) + at junit.framework.TestResult$1.protect(TestResult.java:106) + at junit.framework.TestResult.runProtected(TestResult.java:124) + at junit.framework.TestResult.run(TestResult.java:109) + at junit.framework.TestCase.run(TestCase.java:118) + at org.apache.qpid.testutil.QpidTestCase.run(QpidTestCase.java:157) + at junit.framework.TestSuite.runTest(TestSuite.java:208) + at junit.framework.TestSuite.run(TestSuite.java:203) + at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) + at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) + at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) + at java.lang.reflect.Method.invoke(Method.java:597) + at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210) + at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135) + at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122) + at org.apache.maven.surefire.Surefire.run(Surefire.java:129) + at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) + at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) + at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) + at java.lang.reflect.Method.invoke(Method.java:597) + at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225) + at org.apache.maven.surefire.booter.SurefireBooter.run(SurefireBooter.java:139) + at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:376) + at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) + at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) + at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) + at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) + at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) + at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) + at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) + at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) + at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) + at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) + at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) + at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) + at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) + at java.lang.reflect.Method.invoke(Method.java:597) + at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) + at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) + at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) + at org.codehaus.classworlds.Launcher.main(Launcher.java:375) +java.lang.NullPointerException + at org.apache.qpid.client.handler.ClientMethodDispatcherImpl.newMethodDispatcher(ClientMethodDispatcherImpl.java:86) + at org.apache.qpid.client.protocol.AMQProtocolSession.setStateManager(AMQProtocolSession.java:171) + at org.apache.qpid.client.protocol.AMQProtocolHandler.setStateManager(AMQProtocolHandler.java:750) + at org.apache.qpid.client.AMQConnection.(AMQConnection.java:451) + at org.apache.qpid.client.AMQConnection.(AMQConnection.java:281) + at org.apache.qpid.testutil.QpidTestCase.getConnection(QpidTestCase.java:339) + at org.apache.qpid.test.unit.transacted.TransactedTest.setUp(TransactedTest.java:65) + at junit.framework.TestCase.runBare(TestCase.java:125) + at org.apache.qpid.testutil.QpidTestCase.runBare(QpidTestCase.java:131) + at junit.framework.TestResult$1.protect(TestResult.java:106) + at junit.framework.TestResult.runProtected(TestResult.java:124) + at junit.framework.TestResult.run(TestResult.java:109) + at junit.framework.TestCase.run(TestCase.java:118) + at org.apache.qpid.testutil.QpidTestCase.run(QpidTestCase.java:157) + at junit.framework.TestSuite.runTest(TestSuite.java:208) + at junit.framework.TestSuite.run(TestSuite.java:203) + at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) + at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) + at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) + at java.lang.reflect.Method.invoke(Method.java:597) + at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210) + at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135) + at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122) + at org.apache.maven.surefire.Surefire.run(Surefire.java:129) + at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) + at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) + at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) + at java.lang.reflect.Method.invoke(Method.java:597) + at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225) + at org.apache.maven.surefire.booter.SurefireBooter.run(SurefireBooter.java:139) + at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:376) + at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) + at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) + at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) + at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) + at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) + at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) + at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) + at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) + at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) + at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) + at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) + at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) + at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) + at java.lang.reflect.Method.invoke(Method.java:597) + at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) + at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) + at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) + at org.codehaus.classworlds.Launcher.main(Launcher.java:375) +Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.031 sec <<< FAILURE! +Running org.apache.qpid.test.unit.client.channelclose.CloseWithBlockingReceiveTest +Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec <<< FAILURE! +Running org.apache.qpid.test.unit.basic.PubSubTwoConnectionTest +Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.016 sec <<< FAILURE! +Running org.apache.qpid.test.unit.basic.SelectorTest +Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.016 sec <<< FAILURE! +Running org.apache.qpid.test.unit.topic.DurableSubscriptionTest +Tests run: 4, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 0.015 sec <<< FAILURE! +Running org.apache.qpid.test.unit.client.message.BytesMessageTest +Tests run: 31, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec +Running org.apache.qpid.test.unit.client.message.TextMessageTest +Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec +Running org.apache.qpid.test.unit.xa.TopicTest +Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec +Running org.apache.qpid.test.unit.client.message.StreamMessageTest +Tests run: 33, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec +Running org.apache.qpid.test.unit.client.connection.ConnectionCloseTest +Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec <<< FAILURE! +Running org.apache.qpid.test.unit.close.TopicPublisherCloseTest +Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec <<< FAILURE! +Running org.apache.qpid.test.unit.client.AMQConnectionTest +Tests run: 9, Failures: 0, Errors: 9, Skipped: 0, Time elapsed: 0.032 sec <<< FAILURE! +Running org.apache.qpid.test.unit.client.temporaryqueue.TemporaryQueueTest +Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec <<< FAILURE! +Running org.apache.qpid.test.unit.message.JMSDestinationTest +Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec <<< FAILURE! +Running org.apache.qpid.test.unit.client.connection.ExceptionListenerTest +Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.015 sec <<< FAILURE! +Running org.apache.qpid.client.message.TestMessageHelper +Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec +Running org.apache.qpid.test.unit.basic.MapMessageTest +Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec <<< FAILURE! +Running org.apache.qpid.test.unit.client.connection.ConnectionTest +Tests run: 8, Failures: 0, Errors: 8, Skipped: 0, Time elapsed: 0.563 sec <<< FAILURE! +Running org.apache.qpid.test.unit.message.MessageConverterTest +Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.032 sec +Running org.apache.qpid.test.unit.basic.SessionStartTest +[INFO] ------------------------------------------------------------------------ +[ERROR] BUILD ERROR +[INFO] ------------------------------------------------------------------------ +[INFO] org.apache.qpid.test.unit.basic.SessionStartTest; nested exception is java.lang.reflect.UndeclaredThrowableException: null; nested exception is org.apache.maven.surefire.testset.TestSetFailedException: org.apache.qpid.test.unit.basic.SessionStartTest; nested exception is java.lang.reflect.UndeclaredThrowableException: null + +org.apache.qpid.testutil.VMBrokerSetup.getName() +[INFO] ------------------------------------------------------------------------ +[INFO] For more information, run Maven with the -e switch +[INFO] ------------------------------------------------------------------------ +[INFO] Total time: 45 seconds +[INFO] Finished at: Thu Apr 17 15:48:37 BST 2008 +[INFO] Final Memory: 12M/26M +[INFO] ------------------------------------------------------------------------ diff --git a/documentation/content/xdocs/Distributed Testing.html b/documentation/content/xdocs/Distributed Testing.html new file mode 100755 index 0000000000..8afb7d5ec4 --- /dev/null +++ b/documentation/content/xdocs/Distributed Testing.html @@ -0,0 +1,379 @@ + + + Apache Qpid : Distributed Testing + + + + + + + + + +
+
+ + Apache Qpid : Distributed Testing + +
+
+ This page last changed on Aug 15, 2007 by rupertlssmith. +
+ +

Testing Proposal.

+ +

Use Cases.

+ +

The following usage scenarios are covered by this test framework design proposal:

+ +

Performance Testing.

+ +
    +
  • Distributed testing.
    • +
+ + +

Want to be able to distribute performance tests accross many machines in parallel, in order to more accurately simulate real usage scenarios and to be able to fully stress test the broker under load.
+ Want to be able to run performance tests, with the test parameters configurable, so that any reasonable toplogy can be simulated and performance estimated.

+ +

For example:

+ +
    +
  1. P2P test. On 10 machines, simulating load of 1000 clients. Each machine will run 100 test circuits on 100 connections. Both ends of the test circuit will reside on the same machine, with each client consuming its own messages. Results over all machines to be collated to arrive at total throughput figures.
    2. +
  2. Pub/Sub test. On 10 machines, simulating load of 1000 subscribers, 1 publisher. One machine acts as the sending half of the test circuit. The 1000 subscriber nodes, the receiving end of the circuit, are distributed as evenly as possible accross the other 9 machines. The publisher sends messages and collates throughput or latency measurements on the test circuit.
    3. +
+ + +

System Testing.

+ +
    +
  • Thorough testing.
    • +
  • Functional testing at the product surface; behavioural tests to carry forward as the system evolves.
    • +
+ + +

Configurable framework, capable of exercising every imaginable combination of options, both in-vm broker and standalone, accross one client/test circuit up to many clients/test circuits in parallel.
+ Want to be able to exercise as many different combinations of test configuration parameters in possible in order to generate to the most comprehensive testing of the broker and protocol as possible. Exhaustive testing of every combination will discover bugs.
+ Want to test the system behaviour at its surface. That is, through the JMS API or through a more direct AMQ API where necessary. The test framework will ideally, abstract out the exact details of the API used, in order to allow forward evolution of the AMQ API.
+ Want to be able to set up each producer or consumer in a test circuit identically by default. More specific tests to be able to produce variations on this theme to test specific scenarios. For example test circuits the send both persistent and transient messages etc.

+ +

Build tests out of a standardized construction block.

+ +
    +
  • Diagram: The test circuit.
    • +
+ + +

Publisher/Receiver pair.
+Each end of which is a Producer/Consumer unit.
+ M producers, N consumers, talking over Z destinations.

+ +

The standard consruction block for a test, is a test circuit. This consists of a publisher, and a receiver. The publisher and receiver may reside on the same machine, or may be distributed. Will use a standard set of properties to define the desired circuit topology.

+ +

Tests are always to be controlled from the publishing side only. The receiving end of the circuit is to be exposed to the test code through an interface, that abstracts as much as possible the receiving end of the test. The interface exposes a set of 'assertions' that may be applied to the receiving end of the test circuit.

+ +

In the case where the receiving end of the circuit resides on the same JVM, the assertions will call the receivers code locally. Where the receiving end is distributed accross one or more machines, the assertions will be applied to a test report gethered from all of the receivers. Test code will be written to the assertions making as few assumptions as possible about the exact test topology.

+ +

A test circuit defines a test topology, M producers, N consumers, Z outgoing routes between them.
+ The publishing end of each test circuit always resides on a single JVM, even if M > 1. If publishers are to be distributed accross many machines, the test framework itself provides the scaling by running the same test circuit many times in parallel. This means that it is possible to have an arbitrary number of message publishers accross one or many machines, determined by the test setup.
+ The receiving half of the circuit may be local, in which case all messages come back to the same machine, or distributed in which case they may be received by many machines.
+ There are therefore two ways in which tests may be distributed accross multiple nodes in a network; many test circuits may be distributed and run in parallel and/or the receiving ends of those circuits may be distributed or local.
+ Each node in the network can play up to 2 roles in any given test; publisher or receiver. It is possible to play both roles at once, but would like to have a 'single_role' flag, that can be set to ensure that test nodes taking one role, will not participate in the other for the duration of a test. For example, in the pub/sub test want one publisher and the remaining nodes to distribute the receiver role amongst themselves.

+ +

Probing for the available test topology.

+ +
    +
  • Diagram: The available topology.
    • +
+ + +

When the test distribution framework starts up, it should broadcast an 'enlist' request on a known topic. All available nodes in the network to reply in order to make it known that they are available to carry out tests. For the requested test case, C test circuits are to be run in parallel. Each test defines its desired M by N topology for each circuit. The entire network may be available to run both roles, or the test case may have specified a limit on the number of publishing nodes and set the 'single_role' flag. If the number of publishing nodes exhausts the available network and the single role flag is on, then there are no nodes available to run the receiver roles, the test will fail with an error at this point. Suppose there are P nodes available to run the publisher roles, and R nodes available to run the receiver roles. The C test circuits will be divided up as evenly as possible amongst the P nodes. The C * N receivers will be divided up as evenly as possible amongst the R nodes.

+ +

A more concrete example. There are 10 test machines available. Want to run a pub/sub test with 2 publishers, publishing to 50 topics, with 250 subscribers, measuring total throughput. The distribution framework probes to find the ten machines. The test parameters specify a concurrency level of 2 circuits, limited to 2 nodes, with the single role flag set, which leaves 8 nodes to play the receiver role. The test parameters specify each circuit as having 25 topics, unique to the circuit, and 125 receivers. The total of 250 receivers are distributed amongst the 8 available nodes, 31 each, except for two of them which get 32. The test specifies a duration of 10 minutes, sending messages 500 bytes in size using test batches of 10000 messages, as fast as possible. The distribution framework sends a start signal to each of the publishers. The publishers run for 10000 messages. The publishers request a report from each receiver on their cicruit. The receivers send back to the publishers a report on the number of messages received in the batch. The publishers assert that the correct number for the batch were indeed received, and log a time sample for the batch. This continues for 10 minutes. At the end of the 10 minutes, the publishers collate all of their timings, failures, errors into a log message. The distribution framework requests the test report from each publishing nodes, and these logs are combined together to produce a single log for the entire run. Some stats, such as total time taken, total messages through the system, total throughput are calculated and added as a summary to the log, along with a record of the requested and actual topology used to run the test.

+ +
    +
  • Diagram: The requested test applied onto the available topology.
    • +
+ + +

Test Procedures.

+ +

A variety of different tests can be written against a standard test circuit, many of these will follow a common pattern. One of the aims of using a common test circuit configured by a number of test parameters, is to be able to automate the generation of all possible test cases that can be produced from the circuit combined with the common testing pattern, and an outline of a procedure for doing this is described here. The typical test sequence is described below:

+ +

A typical test sequence.

+ +
    +
  1. Initialize the test circuit from the default parameters, plus specific settings for the test.
    2. +
  2. Create the test circuit. The requested test parameters are applied to the available topology to produce a live circuit.
    3. +
  3. Send messages.
    4. +
  4. Request a status report.
    5. +
  5. Assert conditions on the publishing end of the circuit.
    6. +
  6. Assert conditions on the receiving end of the circuit.
    7. +
  7. Pass or fail the test.
    8. +
+ + +

The thorough test procedure.

+ +

The thorough test procedure uses the typical test sequence described above, but generates all of combinations of test parameters and corresponding assertions against the results.

+ +

The all_combinations function produces all combinations of test parameters described in Appendix A.

+ +

all_combinations : List<Properties>

+ +

The expected_results function, produces a list of assertions, given a set of test parameters. For example, mandatory && no_route -> assertions.add(producer.assertMessageReturned), assertions.add(receiver.assertMessageNotReceived).

+ +

expected_results: Properties -> List<Assertions>

+ +

For parameters : all_combinations
+ test_circuit = new TestCircuit(parameters).
+ test_circuit.start.

+ +

Send mesages.
+ Request status.

+ +

For assertion : exected_results(parameters)
+ Assert(assertion).

+ +

Appendix A - Test Parameters.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
  Possible Values Default Value
Connection properties.   
broker tcp, vm tcp://localhost
vhost   <empty>
username   guest
password   guest
Topology properties.   
max_publishing_node   1
single_role true, false true
Circuit properties. Total: 2^2 = 4 combinations.  
num_publishers   1
num_consumers   1
num_destinations   1
base_out_route_name   ping
base_in_route_name   pong
bind_out_route true, false true
bind_in_route true, false false
consumer_out_active true, false true
consumer_in_active true, false false
JMS flags and options. Total: 2 * 2 * 2 * 6 = 48 combinations.  
transactional true, false false
persistent true, false false
no_local true, false false
ack_mode tx, auto, client, dups_ok, no_ack, pre_ack auto
AMQP/Qpid flags and options. Total: 2^4 = 16 combinations.  
exclusive true, false false
immediate true, false false
mandatory true, false false
durable true, false false
prefetch_size   
header_fields   
Standard test parameters. Total: 3 combinations.  
message_size no_body, one_body, multi_body one_body
num_messages   100
outgoing_rate   
inbound_rate   
timeout   30 seconds
tx_batch_size   100
max_pending_data   
+ +

Total combinations over all test parameters: 4 * 48 * 16 * 3 = 9216 combinations.

+ +

Defaults give an in-VM broker, 1:1 P2P topology, no tx, auto ack, no flags, publisher -> receiver route configured, no return route.

+ +

Appendix B - Clock Synchronization Algorithm.

+ +

On connection/initialization of the framework, synch clocks between all nodes in the available toplogy. For in vm tests, the clock delta and error will automatically be zero. For throughput measurements, the overall test times will be long enough that the error does not need to be particularly small. For latency measurements, want to get accurate clock synchronization. This should not be too hard to achieve over a quiet local network.

+ +

After determining the list of clients available to conduct tests against, the Coordinator synchronizes the clocks of each in turn. The synchronization is done against one client at a time, at a fairly low messaging rate over the Qpid broker. If needed, a more accurate mechanism, using something like NTP over UDP could be used. Ensure the clock synchronization is captured by an interface, to allow better solutions to be added at a later date. Here is a simple algorithm to get started with:

+ +
    +
  1. Coordinator tells client to synchronize its clock with the coordinators time.
    2. +
  2. Client stamps current local time on a "time request" message and sends to Coordinator.
    3. +
  3. Upon receipt by Coordinator, Coordinator stamps Coordinator-time and returns.
    4. +
  4. Upon receipt by Client, Client subtracts current time from sent time and divides by two to compute latency. It subtracts current time from Coordinator time to determine Client-Coordinator time delta and adds in the half-latency to get the correct clock delta.
    5. +
  5. The first result should immediately be used to update the clock since it will get the local clock into at least the right ballpark.
    6. +
  6. The Client repeats steps 1 through 3, 25 or more times, pausing a few tens of milliseconds each time.
    7. +
  7. The results of the packet receipts are accumulated and sorted in lowest-latency to highest-latency order. The median latency is determined by picking the mid-point sample from this ordered list.
    8. +
  8. All samples above approximately 1 standard-deviation from the median are discarded and the remaining samples are averaged using an arithmetic mean.
    9. +
+ + +

The above algorithm includes broker latency, two network hops each way, plus possible effects of buffering/resends on the TCP protocol. A fairly easy improvement on it might be:

+ +
    +
  1. Coordinator tells client to synchronize its clock with the coordinators time, provides a port/address to synchronize against.
    2. +
  2. Clients sends UDP packets to the Coordinators address and performs the same procedure as outlined above.
    3. +
+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Download.html b/documentation/content/xdocs/Download.html new file mode 100755 index 0000000000..beb1372e2b --- /dev/null +++ b/documentation/content/xdocs/Download.html @@ -0,0 +1,84 @@ + + + Apache Qpid : Download + + + + + + + + + +
+
+ + Apache Qpid : Download + +
+
+ This page last changed on Apr 14, 2008 by aidan. +
+ +

Introduction to releases:

+ +

Qpid implements the AMQP Specification, and as the specification has progressed Qpid is keeping up with the updates. This means that different Qpid versions support different versions of AMQP. Here is a simple guide on what use.

+ +
    +
  • M1 Release is our first release and support AMQP 0-8. Not recommended anymore
    • +
  • M2.x Release supports AMQP 0-9. The use of these versions are recommended. – download below
    • +
  • Trunk (M3) supports AMQP 0-10 and some backwards compatibility with AMQP 0-9, the C++ Broker, Java, and Python Client support 0-10, The Java client support 0-9 & 0-10. Other clients and Java broker (will support both AMQP 0-9 and AMQP 0-10) to be updated. Recommended development tree, or running AMQP 0-10 – use svn Source Repository or download a clean build cruisecontrol builds
    • +
+ + + +

Production Releases

+ +

These releases are well tested and appropriate for production use. M2 is the lastest IPMC ratfied release from Qpid.

+ +

Full release: http://people.apache.org/dist/incubator/qpid/M2-incubating/

+ + + + +

If you have any questions please mail the user list user list

+ + +

Development Releases

+ +

These releases are intended for testing and previewing new features. They have been tested and meet reasonable quality standards.

+ +

As Qpid tracks AMQP working group public work aggressively it might be worth mailing the dev list to check the state of svn trunk and if you want to use that to understand the current compatibility matrix.

+ +

RPMs for the builds of trunk that have passed all the tests get automatically posted and are available at cruisecontrol

+ +

Beta builds of M2.1 are available from http://people.apache.org/~aidan/qpid-M2.1-RC5/

+ +

Previous Releases

+ + +

The M1 release:
+http://people.apache.org/dist/incubator/qpid/M1-incubating/

+ + + + + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Example Classes.html b/documentation/content/xdocs/Example Classes.html new file mode 100755 index 0000000000..055d085523 --- /dev/null +++ b/documentation/content/xdocs/Example Classes.html @@ -0,0 +1,119 @@ + + + Apache Qpid : Example Classes + + + + + + + + + +
+
+ + Apache Qpid : Example Classes + +
+
+ This page last changed on Apr 06, 2007 by mmccorma. +
+ +

Overview

+ +

Some example client code is provided to help you get started, using JNDI and JMS.

+ +

Downloading the source

+ +

The source code for the example client classes being provided is contained in the example package which can be found in:

+ +

https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/java/client/example/

+ +

Building the Example source

+ +

You can build the example source using Maven by simply typing 'mvn' in the example directory.

+ +

Notes on the source package

+ +

Note that if you wish to build the example client code from within your IDE you will need to add the following jars contained in the Qpid binary release into your classpath:

+ +
+
qpid-client-<RELEASE>-incubating-<MILESTONE>.jar
+qpid-common-<RELEASE>-incubating-<MILESTONE>.jar
+geronimo-jms_1.1_spec-1.0.jar
+
+
+ +

At the time of writing, RELEASE is '1.0' and MILESTONE is 'M2-SNAPSHOT'.

+ +

NB: At runtime, you'll need to put all the jars in the client/lib dir into your classpath along with these jars.

+ +

The example packages classes currently use log4j for logging. You may instead wish to amend the logging and exception handling in line with your project standards.

+ +

Class Overview

+ +

Essentially we have provided example client classes to act as a publisher and a subscriber for handling messages using AMQ, as far as possible via JMS.

+ +

Contributions to the example classes are most welcome. Please send your classes to our qpid-dev mailing list.

+ +

Basic Classes

+ +

This section outlines the classes that you're likely to find most useful.

+ +

Publisher

+ +

This class contains the methods for publishing messages to a queue, using the example.properties file to populate the initial context and provide an example queue and topic.

+ +

FileMessageDispatcher

+ +

This class provides a simple wrapper around the publisher for dispathcing messages from file input, providing a really easy way to get started publishing messages. So, first create some files you'd like to use as payload for your test messages.

+ +

Then, you simply pass one argument to the FileMessageDispatcher class which is the path to your test message files. The dispatcher will then create a message from each file in the directory. You can opt to use the path to a single file as an alternative, in the same way.

+ +

Subscriber

+ +

This class acts as a consumer of messages sent to a queue.

+ +

Helper Classes/Exceptions

+ +

This section gives some additional information about helper classes in the example packages.

+ +

MessageFactory

+ +

This class constructs a message with payload from an input file provided and sets a property on the message using the filename.

+ +

MessageFactoryException

+ +

Exception thrown if a message cannot be created in the factory class.

+ +

Examples Using AMQP Immediate Delivery Feature

+ +

MonitorMessageDispatcher

+ +

This is an additional wrapper class to be run independently as the monitor which allows you to provide a heartbeat (set to 20 seconds intervals but can be changed at will) being consumed by the example subscriber. When we detect that the subscriber has stopped, you can opt to make a call to an application specific 'recovery process' by amending the exception handling in the main method when a UndeliveredMessageException is caught (marked by a TODO), or simply exit gracefully if appropriate.

+ +

UndeliveredMessageException

+ +

Thrown when the subscriber is not there to read the monitor traffic which has been marked as for immediate delivery.

+ + + +

MonitoredSubscriber

+ +

Subclass of the Subscriber which also reads messages from the monitor queue to let us know that it's consuming ok.

+ +

The shared package contains utility classes for file manipulation etc and constants for general use (to reduce the maintenance overhead) which could perhaps be replaced with config properties as appropriate.

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/FAQ.html b/documentation/content/xdocs/FAQ.html new file mode 100755 index 0000000000..314f9041d0 --- /dev/null +++ b/documentation/content/xdocs/FAQ.html @@ -0,0 +1,79 @@ + + + Apache Qpid : FAQ + + + + + + + + + +
+
+ + Apache Qpid : FAQ + +
+
+ This page last changed on Jun 29, 2007 by ritchiem. +
+ + + + + +

Errors

+ +

I get the following error on connection "Server Connection Failed Reason: Qpid server connection timed out" ?

+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/GSoC.html b/documentation/content/xdocs/GSoC.html new file mode 100755 index 0000000000..93b22f1859 --- /dev/null +++ b/documentation/content/xdocs/GSoC.html @@ -0,0 +1,182 @@ + + + Apache Qpid : GSoC + + + + + + + + + +
+
+ + Apache Qpid : GSoC + +
+
+ This page last changed on Apr 02, 2008 by mmccorma. +
+ +

GSoC Projects and who is doing what:

+ + +

Qpid Demo - two projects (one for AMQP 0-9 and one for AMQP 0-10)

+ +

Candidates: Senaka Fernando, Buddika Laknath

+ +

Project Goal: Create a multi language Demo for Qpid, and use the demo as source to create the Qpid getting Started pages

+ +

Mentor: Carl/Rajith

+ +

Project Description:

+ +

The Qpid project likes to have an enterprise grade demo that reflects the messaging capabilities of the AMQP (www.amqp.org) protocol that uses brokers written in Java and C++ and the clients written in Java/JMS, c++, python, ruby, .NET

+ +

The Demo ca use any client server problem (like bank, stock, render farm, travel site etc) to illustrate the capabilities of the Qpid.

+ + + + +

AMQP mgmt Bridge - JMX

+ +

Candidates: Le Duc Bao,Lahiru Gunathilaka

+ +

Project Goal: Create a dynamic bridge from AMQP-mgmt protocol to JMX to facilitate std management console integration

+ +

Mentor: Marnie/Aidan/Arnaud ?

+ +

Project Description:

+ +

Project is to create a process will receive management Data through the AMQP mgmt protocol and translate those into JMX. This will allow the C++ broker to also be hooked into a JMX allow for all the instrumentation data to be read from JMX, all the methods to be invoked, and the configuration to be updated through standard JMX consoles.

+ +

Note that all the schema is dynamic, so the bridge need to configure itself at runtime, so this service should derive it's behavior from the schema provided to it.

+ +

AMQP mgmt side protocol can be found here: http://cwiki.apache.org/qpid/management-design-notes.html

+ +

To play with it, build the C++ broker
+./bootstrap
+./configure
+make

+ +

on linux, the to run the cmd line mgmt set the PYTHONPATH and run it from mgnt-cli

+ +

You should pretty quickly see how the objects get dynamically build and how they are layed out, these can then quite simple be dynamically mapped to JMX.

+ +

Implementation language is Java

+ +

AMQP mgmt Bridge - WS-DM

+ +

Candidates: Rahul Mehta

+ +

Project Goal: Create a bridge between AMQP-JMX and WS-DM

+ +

Mentor: Arnaud

+ +

Project Description:

+ +

Project is to to expose the AMQP JMX-instrumented applications (Java broker and JMX/C++ management bridge) using MS-DM interfaces. Referring to the JMX architecture, this mapping should be addressed through a JMX-WS-DM connector. This will allow any qpid broker to be hooked into industry standard management product line like BMC, Tivoli, etc.

+ +

current qpid Java broker JMX can be found here: http://cwiki.apache.org/qpid/jmx-management-console.html

+ +

To play with it, you should build the Java broker

+ +

Implementation language is Java.

+ +

JMX Cli

+ +

Candidates: Lahiru Gunathilaka, Ruchira Wageesha

+ +

Project Goal: Provide the ability to access Java Broker mgmt info from cmd line.

+ +

Secondary Goal: Integrate with AMQP mgnt protocol ??

+ +

Mentor: Adian/Marnie/Martin

+ +

Project Description:

+ +

Design and implement a simple solution, runnable from the command line, for extracting useful JMX information from the Qpid Java Broker. Solution should be configurable at runtime to allow users to decide which bits of info they're interested in and when. Might be nice to see the information extracted in a report format

+ +

More info:

+ +

Currently, the Qpid Java broker provides several JMX methods to all users/applications to extract information about queues etc on the broker. We have used this information for two purposes: exposing management details in the existing Eclipse RCP Management Console UI and also to provide alerting in the broker log when certain configurable thresholds are reached e.g. maximum queue size etc.

+ +

However, some of our users have expressed an interest in being able to extract JMX information more simply i.e. without the constraints our existing confgurable alerting brings with it and also independently of the UI.

+ +

Thus, an application which could be called from the command line on Windows, Unix (Solaris) and Linux would be invaluable for our user projects.

+ +

Ideally this CLI would expose all the JMX calls in a simple wrapper and perhaps allow the user to dump the results to an XML file or a web page.

+ +

This is not intended to be too heavily prescriptive and is really intended as a starter for ten !

+ +

Qpid-java-broker-config

+ +

Candidates: Sachith Danushka.

+ +

Project Goal: Rationalize the configuration in the Java Broker to get it more consistent

+ +

Mentor: Adian/Marnie/Martin

+ +

Project Description:

+ +

Refactor Qpid Java Broker configuration into a more elegant xml schema, with xsd, covering all existing configuration options and allowing for extension. Additionally implement a module to validate broker configuration files, which could be run standalone i.e. before starting a broker, to check that they're well formed and validate against the xsd.

+ +

More info:

+ +

Currently the broker configuration for the Qpid Java Broker is a little untidy. There's the bulk of the core broker configuration, much of which the majority of our end users won't want to change much, in the default config.xml files that we ship. On top of that we have a set of properties for the virtualhosts (which includes the ability to define per host some queues which will always exist on broker startup etc) in a separate file.

+ +

At the moment, if you edit the config.xml file you're using and accidentally damage or remove an important section the broker will blow up in an unexpected fashion. Creating an xsd and validating the config.xml at startup (probably as a switch on/off-able option !) would help to avoid this possibility.

+ +

We could also provide more information about what the config file contains in a self-documenting way. I'd suggest we need to restructure the config set up too - the virtualhosts file is at the very least badly named, but probably not really fit for purpose.

+ +

qpid-android-demo

+ +

Project Goal:
+Implement a simple demo on Android using the Qpid client to send messages to and from a broker, such as stock price information and trade orders

+ +

Contact person: Aidan Skinner <aidan AT apache DOT org>

+ +

Project Description:

+ +

Android is hot, Qpid is hot, porting the Qpid client to Android and getting it to pull some information and publish some would be hot.

+ +

DBus over Qpid

+ +

Project Goal:
+Implement an AMQP transport for DBus using Qpid.

+ +

Contact Person: Aidan Skinner <aidan AT apache DOT org>

+ +

Project Description:
+ Running DBus over AMQP would allow some interesting use cases, such as home automation, automatic synchronisation and the like, turning it into a true network bus.

+ +

You would need to be familiar with C, C++, Python or Java, and would ideally have experience working with disparate Free Software communities.

+ + +

Apache Derby Datastore

+ +

Project Goal:
+Implement a datastore backed by Hibernate or Apache Derby

+ +

Contact Person: Aidan Skinner <aidan AT apache DOT org>

+ +

Project Description:

+ +

Create a persistent datastore for Qpid that uses JDBC to connect to a database and which uses Apache Derby as a default backend. Bonus points for implementing it using hibernate so it's easily portable across different databases.

+ +

You would need to be familiar with Java, JDBC, Hibernate and SQL.

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Getting Involved.html b/documentation/content/xdocs/Getting Involved.html new file mode 100755 index 0000000000..a8917d0cc3 --- /dev/null +++ b/documentation/content/xdocs/Getting Involved.html @@ -0,0 +1,80 @@ + + + Apache Qpid : Getting Involved + + + + + + + + + +
+
+ + Apache Qpid : Getting Involved + +
+
+ This page last changed on Apr 11, 2008 by cctrieloff. +
+ +

There are many ways you can get involved in Qpid:

+ +

1. Use Qpid and post us your feedback to qpid-dev@incubator.apache.org
+2. Participate on the mailing lists.
+3. Contibute via open JIRA JIRA issues
+4. Review the current code
+5. Help write user documentation or wiki documentation
+6. Help write user examples.

+ +

Plesae be sure to take a look at the coding guidelines for the setcion of the project that you contribute to

+ + + + +

Some Ideas to contribute

+ +

Themes and JIRA's for our road map are located here RoadMap Please fell free to mail the dev list if you want to pick up any of these items on the project.

+ + +

Google Summer of Code GSoC

+ + +

Becoming a committer:

+ +

Qpid uses the following guidelines for voting in new committers. First off we would like new committers to have provided meaningful contribution to the project. By contributions we include development (tests, features, examples) or documentation through patches and interactions with the project through lists and JIRA.

+ +

The key question is what does the Qpid project consider to be a meaningful contribution to be come a committer. As this bar is set for all new commiters Qpid will be conservative in general with adding new committers.

+ +

The Qpid project will look to see if someone consistently provides quality contributions and interactions with the project over a period or 1 to 2 months. Based on that the PPMC will vote the new committers onto the project.

+ +

If you have any question please mail qpid-dev@incubator.apache.org or qpid-private@incubator.apache.org

+ +

Many thanks for you interest,
+the Qpid team.

+ +

Joining the PPMC

+ +

While we (Qpid) are still in the incubator, if you want to join the PPMC, once you have become a committer please just mail he qpid-private@i.a.o list and request to be added to the PPMC. Once we graduate this will be done with a vote buy the then action PMC.

+ + + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Getting Started Guide.html b/documentation/content/xdocs/Getting Started Guide.html new file mode 100755 index 0000000000..11782603bd --- /dev/null +++ b/documentation/content/xdocs/Getting Started Guide.html @@ -0,0 +1,250 @@ + + + Apache Qpid : Getting Started Guide + + + + + + + + + +
+
+ + Apache Qpid : Getting Started Guide + +
+
+ This page last changed on Apr 22, 2008 by mmccorma. +
+ +

Installing & Using Qpid (Java)

+ + +

Introduction

+ +

The information below details how to install and use the main Broker and Client packages.

+ +

Essentially, to make use of the Qpid AMQP infrastructure you need to be able to run a broker instance to handle messaging traffic and talk to your client code. Your own application code will make use of the Qpid client package provided to interface with the broker.

+ +

Related pages to get you going

+ + + + +

Minor apologies since these instructions are heavily linux/unix focused. If you have difficulty using our .bat script (see below) please email qpid-users for assistance.

+

Prerequisites

+ +

The Qpid broker requires Java 5 or later to be available. For maximum performance Java 6 is recommended. Note that JDK 5 has a bug which may cause problems, so plase use versions later than 1.5.0_15 !

+ +

The Java JMS client can be run using Java 1.4, 5 or 6. Note that the 1.4 client libraries come in a separate package.

+ +

Downloading & Installing Qpid

+ +

The latest binary and source distributions of Qpid Broker and Client packages are available from the downloads page.

+ +

If you want to use a newer version than an official release then you should check out the code from the Subversion repository and then consult the Build How To page.

+ +

Broker Install

+ +

Unpack the archive into any directory of your choice e.g c:/qpid

+ +

Once unpacked, the package will be installed in a directory with a release label (i.e. qpid-1.0-incubating-M2) and the directories underneath should look something like this:

+ +

/bin

+ +

Contains various startup utilities:

+ +

qpid-server is a bash script which runs the broker on linux/unix. You should set the environment variable QPID_HOME to point at your install path e.g. C:/qpid/qpid-1.0-incubating-M2. This enables the startup script to find default config files in the installed etc directory.

+ +

qpid-run is a script which allows shell commands to be executed which the qpid-server script utilises.

+ +

qpid-server.bat is a dos script which runs the broker on Windows. See note above about QPID_HOME.

+ +

The other scripts in this directory can be safely ignored for now.

+ +

/lib

+ +

Contains all the jars used by the broker, mainly in their own subdirectories.

+ +

The broker-launch.jar contains a manifest file which puts the requisite jars into the classpath for broker startup.

+ +

Other files & jars in here can be safely ignored for now.

+ +

/etc

+ +

Contains the config files used by the broker on startup.

+ +

/client

+ +

This comes with the broker package at the moment and contains the client package. The client can also be downloaded independently. See client section below for details.

+ +

/doc

+ +

Contains javadoc for the broker.

+ +

If running on a unix or linux platform check that the appropriate permissions have been applied to the .sh scripts. If not, then update i.e. chmod 755 *.sh

+ +

Environment Variables

+ +

Qpid Locations

+ +

You should set the following variables:

+ +

QPID_HOME - specifies where your install of Qpid exists, used for broker lookups of files etc
+QPID_WORK - defines location of all working files created by the broker including log and db (i.e. BDB if used)
+PATH - ensure that the QPID_HOME/bin directory is added to your path so that the server scripts can run

+ +
    +
  1. First set the QPID_HOME variable to reflect the root of your installation. For example, if you have installed the broker package into a directory <homedir>/broker/qpid-xx then you should set the QPID_HOME variable to <homedir>/broker/qpid-xx.
    2. +
  2. You can also set the QPID_WORK variable in order to control the destination directory for the log dir into which broker logging is generated. For example, if you wish to set the working directory to be <homedir>/working you should set the QPID_WORK directory to be <homedir>/working. Note that the QPID_WORK variable defaults to the current user's home directory if not set.
    3. +
  3. Then set your PATH variable appropriately to include the bin dir
    4. +
+ + +

Setting JAVA environment

+ +

You must make the JDK available available by setting the JAVA_HOME environment variable and adding the JAVA_HOME/bin directory to your PATH.

+ +

You should use JDK 1.6, or at least a version later than 1.5_15.

+ +

For example, if you have installed the JDK in /home/jdk1.6 then:
+JAVA_HOME should be set to /home/jdk1.6
+PATH should include /home/jdk1.6/bin

+ +

To check that you have completed this change successfully, simply type

+ +

java -version

+ +

You should see something like

+ +

java version "1.6.0_02"
+Java(TM) SE Runtime Environment (build 1.6.0_02-b06)
+Java HotSpot(TM) Server VM (build 1.6.0_02-b06, mixed mode)

+ +

The Qpid scripts set the classpath and other flags required for the broker to run.

+ +

Configuration

+ +

We ship two example configuration files with the Java broker:

+ +

persistent_confg.xml - when you want to use any persistent messages with the Qpid broker (currently with BDB)
+transient_config.xml - for transient messaging only

+ +

You can simply use one of these config files to get started, using the -c option to specify to the qpid-server script. See details next in the next section for more info on command line options.

+ +

Please visit our 3rd Party Libraries page to get more generic information on how to set up your chosen persistence implementation for Qpid.

+ +

Running the Qpid Broker

+ +

There are scripts provided to run the broker on Windows and on Linux/Unix.

+ +

Running the Qpid Broker on Linux/Unix

+ +
    +
  • Make sure you have set the QPID_HOME variable as specified above, and QPID_WORK if you don't want the default
    • +
  • One of the config files (persistent_config.xml or transient_config.xml) supplied in the etc directory one level below your root dir probably doesn't need modification and should be passed in using -c and the path to your config file
    • +
  • Then run the qpid-server script from the root dir of your install. (The qpid-server script also supports cygwin environments.)
    • +
+ + +

Command Line Arguments

+

You can get a list of all command line arguments by using the -h argument.

+ +

The following command line options are available:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Option Long Option Description
b bind Bind to the specified address overriding any value in the config file
c config Use the given configuration file
h help Prints list of options
l logconfig Use the specified log4j.xml file rather than that in the etc directory
p port Specify port to listen on. Overrides value in config file
v version Print version information and exit
w logwatch Specify interval for checking for logging config changes. Zero means no checking
+ +

For more detailed information on configuration, please see Qpid Design - Configuration

+ +

Checking the broker has started up

+ +

You can check that the broker has started up successfully by viewing the output it sends to stdout and looking for the start up port info:
+2006-07-06 09:18:24,264 INFO  [main] server.Main (Main.java:181) - Starting Qpid.AMQP broker
+2006-07-06 09:18:24,331 INFO  [main] server.Main (Main.java:251) - Qpid.AMQP listening on non-SSL address 0.0.0.0/0.0.0.0:5672

+ +

Note that you may have to edit the log4j.xml in the /etc directory to add an appender for the server.Main class to see loggeds output like this on startup.

+ +

Running the Qpid Broker on Windows

+ +

Simply set the QPID_HOME variable and run the .bat script. All other details as identical to running on Linux/Unix.

+ +

So for example:
+qpid-server.bat

+ +

Getting Help

+ +

You can view our FAQ and Troubleshooting Guide for assistance. If you can't find the information that you need there, then email our qpid users list

+ +
+
+ Attachments: +
+ +
+ + set_classpath.bat (application/octet-stream) +
+ + set_classpath.sh (application/octet-stream) +
+
+ +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Getting Started Guide_attachments/set_classpath.bat b/documentation/content/xdocs/Getting Started Guide_attachments/set_classpath.bat new file mode 100755 index 0000000000..d528967024 --- /dev/null +++ b/documentation/content/xdocs/Getting Started Guide_attachments/set_classpath.bat @@ -0,0 +1,50 @@ +@REM Licensed to the Apache Software Foundation (ASF) under one +@REM or more contributor license agreements. See the NOTICE file +@REM distributed with this work for additional information +@REM regarding copyright ownership. The ASF licenses this file +@REM to you under the Apache License, Version 2.0 (the +@REM "License"); you may not use this file except in compliance +@REM with the License. You may obtain a copy of the License at +@REM +@REM http://www.apache.org/licenses/LICENSE-2.0 +@REM +@REM Unless required by applicable law or agreed to in writing, +@REM software distributed under the License is distributed on an +@REM "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +@REM KIND, either express or implied. See the License for the +@REM specific language governing permissions and limitations +@REM under the License. + +@REM Helper script to set classpath for running Qpid example classes +@REM NB: You must add the Qpid client and common jars to your CLASSPATH +@REM before running this script + +@echo off + +if "%QPID_HOME%" == "" GOTO ERROR_QPID_HOME + +set QPIDLIB=%QPID_HOME%\lib + +if "%CLASSPATH%" == "" GOTO ERROR_CLASSPATH + +set CLASSPATH=%CLASSPATH%;%QPIDLIB%\backport-util-concurrent-2.2.jar +set CLASSPATH=%CLASSPATH%;%QPIDLIB%\geronimo-jms_1.1_spec-1.0.jar +set CLASSPATH=%CLASSPATH%;%QPIDLIB%\commons-collections-3.1.jar +set CLASSPATH=%CLASSPATH%;%QPIDLIB%\commons-configuration-1.2.jar +set CLASSPATH=%CLASSPATH%;%QPIDLIB%\commons-cli-1.0.jar +set CLASSPATH=%CLASSPATH%;%QPIDLIB%\commons-lang-2.1.jar +set CLASSPATH=%CLASSPATH%;%QPIDLIB%\commons-logging-api-1.0.4.jar +set CLASSPATH=%CLASSPATH%;%QPIDLIB%\commons-logging-1.0.jar +set CLASSPATH=%CLASSPATH%;%QPIDLIB%\log4j-1.2.12.jar +set CLASSPATH=%CLASSPATH%;%QPIDLIB%\mina-core-1.0.0.jar +set CLASSPATH=%CLASSPATH%;%QPIDLIB%\mina-filter-ssl-1.0.0.jar +set CLASSPATH=%CLASSPATH%;%QPIDLIB%\mina-java5-1.0.0.jar +set CLASSPATH=%CLASSPATH%;%QPIDLIB%\slf4j-simple-1.0.jar + +GOTO END + +:ERROR_CLASSPATH +Echo Please set set your CLASSPATH variable to include the Qpid client and common jars. Exiting .... +:ERROR_QPID_HOME +Echo Please set QPID_HOME variable. Exiting .... +:END diff --git a/documentation/content/xdocs/Getting Started Guide_attachments/set_classpath.sh b/documentation/content/xdocs/Getting Started Guide_attachments/set_classpath.sh new file mode 100755 index 0000000000..bab9cbad77 --- /dev/null +++ b/documentation/content/xdocs/Getting Started Guide_attachments/set_classpath.sh @@ -0,0 +1,83 @@ +#!/bin/sh -xv +# +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. +# + +# Helper script to set classpath for running Qpid example classes +# NB: You must add the Qpid client and common jars to your CLASSPATH +# before running this script + + +cygwin=false +if [[ "$(uname -a | fgrep Cygwin)" != "" ]]; then + cygwin=true +fi + +#Should have set the QPID_HOME var after install to the working dir e.g. home/qpid/qpid-1.0-incubating-M2-SNAPSHOT +if [ "$QPID_HOME" = "" ] ; then + echo "ERROR: Please set QPID_HOME variable. Exiting ...." + exit 1 +else + QPIDLIB=$QPID_HOME/lib +fi + +if $cygwin; then + QPIDLIB=$(cygpath -w $QPIDLIB) +fi + +if [ "$CLASSPATH" = "" ] ; then + echo "ERROR: Please set set your CLASSPATH variable to include the Qpid client and common jars. Exiting ...." + exit 2 +fi + +#Converts paths for cygwin if req +#Some nasty concatenation to get round cygpath line limits +if $cygwin; then + SEP=";" + CLASSPATH=`cygpath -w $CLASSPATH` + CLASSPATH=$CLASSPATH$SEP`cygpath -w $QPIDLIB/backport-util-concurrent-2.2.jar` + CLASSPATH=$CLASSPATH$SEP`cygpath -w $QPIDLIB/geronimo-jms_1.1_spec-1.0.jar` + CLASSPATH=$CLASSPATH$SEP`cygpath -w $QPIDLIB/commons-collections-3.1.jar` + CLASSPATH=$CLASSPATH$SEP`cygpath -w $QPIDLIB/commons-configuration-1.2.jar` + CLASSPATH=$CLASSPATH$SEP`cygpath -w $QPIDLIB/commons-cli-1.0.jar` + CLASSPATH=$CLASSPATH$SEP`cygpath -w $QPIDLIB/commons-lang-2.1.jar` + CLASSPATH=$CLASSPATH$SEP`cygpath -w $QPIDLIB/commons-logging-api-1.0.4.jar` + CLASSPATH=$CLASSPATH$SEP`cygpath -w $QPIDLIB/commons-logging-1.0.jar` + CLASSPATH=$CLASSPATH$SEP`cygpath -w $QPIDLIB/log4j-1.2.12.jar` + CLASSPATH=$CLASSPATH$SEP`cygpath -w $QPIDLIB/mina-core-1.0.0.jar` + CLASSPATH=$CLASSPATH$SEP`cygpath -w $QPIDLIB/mina-filter-ssl-1.0.0.jar` + CLASSPATH=$CLASSPATH$SEP`cygpath -w $QPIDLIB/mina-java5-1.0.0.jar` + CLASSPATH=$CLASSPATH$SEP`cygpath -w $QPIDLIB/slf4j-simple-1.0.jar` + export CLASSPATH +else + CLASSPATH=$CLASSPATH:$QPIDLIB/backport-util-concurrent-2.2.jar + CLASSPATH=$CLASSPATH:$QPIDLIB/geronimo-jms_1.1_spec-1.0.jar + CLASSPATH=$CLASSPATH:$QPIDLIB/commons-collections-3.1.jar + CLASSPATH=$CLASSPATH:$QPIDLIB/commons-configuration-1.2.jar + CLASSPATH=$CLASSPATH:$QPIDLIB/commons-cli-1.0.jar + CLASSPATH=$CLASSPATH:$QPIDLIB/commons-lang-2.1.jar + CLASSPATH=$CLASSPATH:$QPIDLIB/commons-logging-api-1.0.4.jar + CLASSPATH=$CLASSPATH:$QPIDLIB/commons-logging-1.0.jar + CLASSPATH=$CLASSPATH:$QPIDLIB/log4j-1.2.12.jar + CLASSPATH=$CLASSPATH:$QPIDLIB/mina-core-1.0.0.jar + CLASSPATH=$CLASSPATH:$QPIDLIB/mina-filter-ssl-1.0.0.jar + CLASSPATH=$CLASSPATH:$QPIDLIB/mina-java5-1.0.0.jar + CLASSPATH=$CLASSPATH:$QPIDLIB/slf4j-simple-1.0.jar + export CLASSPATH +fi + diff --git a/documentation/content/xdocs/Getting Started.html b/documentation/content/xdocs/Getting Started.html new file mode 100755 index 0000000000..bec70f9b83 --- /dev/null +++ b/documentation/content/xdocs/Getting Started.html @@ -0,0 +1,96 @@ + + + Apache Qpid : Getting Started + + + + + + + + + +
+
+ + Apache Qpid : Getting Started + +
+
+ This page last changed on Apr 11, 2008 by cctrieloff. +
+ +

Getting the Bits.

+ +

To work out what to download or where to start Download

+ + +

Running it / Administration

+ +

These sections show you how to run the brokers, basic configuration and management

+ + + + +

Making sure it runs correctly

+ +

For more details on starting the brokers, see Administration section.

+ +

The simplest way to check that the install is working correct is to try some of the examples. Each clients
+has a set of examples included with it (or at least JMS, Java, C++ and Python do)

+ +

If working from svn, a good smoke test is to run the python tests as they can be run against
+any version of AMQP and any broker.

+ +

To do so

+
+
export PYTHONPATH=~/qpid/python  # or wherever you have it
+$./run-tests
+.........EFF.... /.../ #each . is a test E is an error, F is a fail
+
+
+#or to do a specific version
+$./run-tests
+Options:
+  ?/-h/-help             : this message
+  s/-spec <spec.xml> : URL of AMQP XML specification or one of these abbreviations:
+                           0-8 - use the default 0-8 specification.
+                           0-9 - use the default 0-9 specification.
+  e/-errata <errata.xml> : file containing amqp XML errata
+  b/-broker [<user>/<password>@]<host>:<port> : broker to connect to
+  v/-verbose             : verbose - lists tests as they are run.
+  d/-debug               : enable debug logging.
+  i/-ignore <test>       : ignore the named test.
+  I/-ignore-file         : file containing patterns to ignore.
+  S/-skip-self-test      : skips the client self tests in the 'tests folder'
+  F/-spec-folder         : folder that contains the specs to be loaded
+
+ + +

Finally, if developing in svn, each build system has tests integrated into the build system for that language

+ + + +

Your first Hello World

+ + +

API Guides

+ + + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/HermesJMS.html b/documentation/content/xdocs/HermesJMS.html new file mode 100755 index 0000000000..69228f4ad0 --- /dev/null +++ b/documentation/content/xdocs/HermesJMS.html @@ -0,0 +1,98 @@ + + + Apache Qpid : HermesJMS + + + + + + + + + +
+
+ + Apache Qpid : HermesJMS + +
+
+ This page last changed on Oct 19, 2006 by mmccorma. +
+ +


+This is a draft

+ +

Background

+ +

HermesJMS is a console for JMS messaging and supports QPID. This page shows how to configure Hermes with QPID.

+ +

As the QPID codebase is moving quickly forward at the moment and there are some workarounds in place within Hermes to support it, you should ensure that you download the latest Hermes build from HEAD

+ +

Finally, you should familiarise youself with Hermes via the tutorials on the website before continuing. Look at the Tibco EMS and JBoss tutorials for how to use connection factories directly or via JNDI. This page uses them directly.

+ +

Configuring

+ +

To get QPID working, you need to configure the libraries to load via the GUI. Hermes loads up each provider in its own classloader to avoid any dependency problems across providers. This tutorial assumes you've downloaded and built QPID via the ant dist task.

+ +

Configure the CLASSPATH

+ +

Start Hermes and select Options -> Configuration and click on the Providers tab. Create a new classpath group (right click for this) and add the following JARS to it:

+ +

Cannot resolve external resource into attachment.

+ + +

When asked, choose the scan option to get Hermes to search the libraries to find any classes that implement JMS connection factory interfaces, this is essential for the next step.

+ +

Finally, click OK.

+ +

Configure The Session

+ +

Right click on the tree of sessions and select New -> Session. In the session combo box at the top put in the name you want, for example QPID. Its important the next thing you do is select the loader so the dialog can find any connection factories.

+ +

In the Class combo box choose the org.apache.qpid.client.AMQConnectionFactory.

+ +

Next, in the property list for the connection factory, right click to add new properties and use the combo to select which one and add their value.

+ +

Finally, and very importantly, check the Use consumer checkbox at the top. QPID does not support JMS queue browsing but Hermes lets you use a {MessageConsumer instead. Remember of course that if an consumer is currently active you will not get the real queue content, Hermes uses a transacted session and some messages may be uncommitted in another consumers session.

+ +

Add Destinations

+ +

Currently you must manually add queues and topics. You can add them now or later from the New queue, New topic or New durable subscription actions in the toolbar. If you add them now then right click in the destination list to add them.

+ +

The session and destinations should look something like this. Once happy, click OK.

+ +

Cannot resolve external resource into attachment.

+ +

Try a Browse

+ +

Finally, double click on a queue or topic in the newly created session in the tree and you should get see something like the following (assuming you've got something in the queue or being published in the topic to see):

+ +

Cannot resolve external resource into attachment.

+ +

This message is a JMS BytesMessage so there not much to see until you see its really a FIX message and clicking on the FIX tab reveals it.

+ +

Cannot resolve external resource into attachment.

+ +

Other Features

+ +

Refer to the HermesJMS site for how to use all the other feature of HermesJMS with QPID.

+ +

Issues

+ +

1. Queues must already exist before you browse them.

+ +

1. get/setJMSDestination() is not supported on a message so Unknown is shown.

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/How to Use JNDI.html b/documentation/content/xdocs/How to Use JNDI.html new file mode 100755 index 0000000000..45f284d965 --- /dev/null +++ b/documentation/content/xdocs/How to Use JNDI.html @@ -0,0 +1,124 @@ + + + Apache Qpid : How to Use JNDI + + + + + + + + + +
+
+ + Apache Qpid : How to Use JNDI + +
+
+ This page last changed on Apr 02, 2008 by asimon. +
+ +

How to use the PropertiesFileInitialContextFactory

+ +

This ContextFactory uses a java properties file to setup initial values.

+ +

This is the example properties file.

+ +
+
java.naming.factory.initial = org.apache.qpid.jndi.PropertiesFileInitialContextFactory
+
+# use the following property to configure the default connector
+#java.naming.provider.url - ignored.
+
+# register some connection factories
+# connectionfactory.[jndiname] = [ConnectionURL]
+connectionfactory.local = amqp://guest:guest@clientid/testpath?brokerlist='vm://:1'
+
+# register some queues in JNDI using the form
+# queue.[jndiName] = [physicalName]
+queue.MyQueue = example.MyQueue
+
+# register some topics in JNDI using the form
+# topic.[jndiName] = [physicalName]
+topic.ibmStocks = stocks.nyse.ibm
+
+# Register an AMQP destination in JNDI
+#   NOTE: Qpid currently only supports direct,topics and headers
+# destination.[jniName] = [BindingURL]
+destination.direct = direct://amq.direct//directQueue
+
+
+ + +

The property file allows a number of queues to be defined that can then be discovered via JNDI. There are four properties used by the PFICFactory.
+connectionfactory.<jndiname> this is the Connection URL that the connection factory will use to perform connections.
+queue.<jndiname> this defines a jms queue or in amqp a amq.direct exchange
+topic.<jndiname> this defines a jms topic or in amqp a amq.topic exchange
+destination.<jndiname> this takes a Binding URL and so can be used for defining all amq destinations, queues, topics and header matching.

+ +

In all of these properties the <jndiname> is the string value that would be given when performing a lookup.

+ + +

NOTE: This does not create the queue on the broker. You should ensure that you have created the queue before publishing to it. Queues can be declared in the virtualhosts.xml file so that they are created on broker startup, or created dynamically by consuming clients. Topics and other destinations that use temporary queues cannot be created in this way, so a consumer must be created first before publishing messages with mandatory routing.

+ +

Example lookup code

+ +

The bindingValue is the String that would be placed in <jndiname> above.

+ +
Simple JNDI lookup using files
+
// Load the properties file ... 
+Properties properties = new Properties();
+properties.load(propertiesfile_inputStream);
+
+// Create the initial context
+Context ctx = new InitialContext(properties);
+
+// Perform the binds
+object = ctx.lookup(bindingValue);
+
+// Close the context when we're done
+ctx.close();
+
+ +
Simple JNDI lookup using properties
+
final String INITIAL_CONTEXT_FACTORY = "org.apache.qpid.jndi.PropertiesFileInitialContextFactory";
+
+final String CONNECTION_JNDI_NAME = "local";
+final String CONNECTION_NAME = "amqp://guest:guest@clientid/testpath?brokerlist='vm://:1'";
+
+final String QUEUE_JNDI_NAME = "queue";
+final String QUEUE_NAME = "example.MyQueue";
+
+// Set the properties ... 
+Properties properties = new Properties();
+properties.put(Context.INITIAL_CONTEXT_FACTORY, INITIAL_CONTEXT_FACTORY);
+properties.put("connectionfactory."+CONNECTION_JNDI_NAME , CONNECTION_NAME);
+properties.put("queue."+QUEUE_JNDI_NAME , QUEUE_NAME);
+
+// Create the initial context
+Context ctx = new InitialContext(properties);
+
+// Perform the lookups
+ConnectionFactory factory = (ConnectionFactory)ctx.lookup(CONNECTION_JNDI_NAME);
+Queue queue = (Queue)ctx.lookup(QUEUE_JNDI_NAME);
+
+// Close the context when we're done
+ctx.close();
+
+ +

Using Qpid with other JNDI Providers

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Informal M2.1 code review 2008-03-18.html b/documentation/content/xdocs/Informal M2.1 code review 2008-03-18.html new file mode 100755 index 0000000000..9c66f0ce88 --- /dev/null +++ b/documentation/content/xdocs/Informal M2.1 code review 2008-03-18.html @@ -0,0 +1,42 @@ + + + Apache Qpid : Informal M2.1 code review 2008-03-18 + + + + + + + + + +
+
+ + Apache Qpid : Informal M2.1 code review 2008-03-18 + +
+
+ This page last changed on Mar 20, 2008 by ritchiem. +
+ +

rgodfrey, 634720, BasicMessageConsumer.java: add comment to document DUPS_OK and AUTO_ACK closenes
+ritchiem, 635549, SelectorParserTest.java: fix and enable test DONE
+aidan, 637146, AMQConnection.java: add comment
+ritchiem, 637170: jira that only outer failover should rety QPID-855
+ritchiem, 637176: change CancelTest logger to use CancelTest class DONE
+ritchiem, 637977: raise Jira to fix client to not communciate on channels it has been told are closed QPID-865

+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Interop Testing Specification.html b/documentation/content/xdocs/Interop Testing Specification.html new file mode 100755 index 0000000000..f06ca04bd1 --- /dev/null +++ b/documentation/content/xdocs/Interop Testing Specification.html @@ -0,0 +1,1106 @@ + + + Apache Qpid : Interop Testing Specification + + + + + + + + + +
+
+ + Apache Qpid : Interop Testing Specification + +
+
+ This page last changed on Nov 22, 2007 by rupertlssmith. +
+ +

Qpid Interop Testing Spec. Working Copy.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Draft. Rupert Smith. 22nd Feb 2007 Document started.
Working Copy. Rupert Smith. 6th Mar 2007 Document updated from feedback to draft on qpid-dev list. Last requirement # used: 47
Working Copy. Rupert Smith. 7th Mar 2007 Senders and receivers to send reports to coordinator. Reply-to added to broadcast messages. Last requirement # used: 49
Working Copy. Rupert Smith. 13th Mar 2007 Added test case names. Last requirement # used: 52
Working Copy. Rupert Smith. 25th Sept 2007 Added test cases for message size variation. Last requirement # used: 60
Version 2 Work in Progress. Rupert Smith 22nd Nov 2007 Test framework being expanded to cover functional and perforance tests and a much wider variety of testing possibilities.
+ +

Introduction:

+ +

The requirements in this specification use a common format, an example of which is given below:

+ + + + + + + +
RE-1. Sample Requirement. A brief descritpion of the requirement.
+ +

The requirements are numbered from 1.

+ +

Purpose:

+ +
    +
  • Test sending from and receiving by each of the clients in Qpid over both of the broker implementations.
    • +
+ + +
    +
  • Enable testing of any JMS compliant product, by keeping a pure JMS sub-set of the testing framework seperate. This only applies to Java messaging client implementations.
    • +
+ + +
    +
  • Provide a parameter driven test framework, that can be used to generate many testing scenarios for different messaging modes.
    • +
+ + +
    +
  • Allow functional testing of messaging at the product surface, through the standard interfaces/protocols (JMS, AMQP), so that the same test suite may be applied over different implementations.
    • +
+ + +
    +
  • Allow tests to be posed in terms of abstract asynchronous messaging concepts that AMQP and JMS support, rather than at the level of direct interfaces. This allows the same tests to carry forward as standards and products evolve.
    • +
+ + +
    +
  • Enable interopability testing between any AMQP compliant components, not just those in Qpid.
    • +
+ + +
    +
  • Allow performance testing to be carried out accross a distributed set of edge nodes connected to a messaging broker.
    • +
+ + +
    +
  • Make tests robust enough to run as part of an automated build. The scripts should pass or fail, not hang, wait forever, run out of memory or otherwise cause an automated build process to fail to complete.
    • +
+ + +
    +
  • Be capable of running the full test suite on several machines in a hands free way. In particular C++ tests need to run on unix and .Net on windows, necessitating a multi-box solution for full interop testing.
    • +
+ + +
    +
  • Be capable of running the same test cases accross message topologies ranging from a single test node running in the same process as a broker, to many test nodes running on different machines, remotely connected to a broker.
    • +
+ + +

Constraints:

+ + + + + + + + + + + + +
IOP-1. Operating System. The test client scripts must run on Unix and Windows. If a test client implementation is only available on one of these platforms it only needs to run on its supported platform.
IOP-2. Scripting Language. Each test client must be startable from a Unix shell script. Tests run on Windows will use Cygwin to run these scripts. There is no need to support Windows .bat scripts.
+ +

Functional Requirements:

+ +

Introduction.

+ +

These requirements describe the behaviour of test clients for testing between different client implementations of AMQP. Each client is expected to be a single program that is capable of sending test messages to other clients and receiving and responding to test messages received from other test clients. The clients are not to be run as seperate programs for the sending and receiving parts for the sake of convenience in being able to run the clients as part of an automated build. The clients will listen for control messages broadcast by a master coordinator, to enlist them in tests, tell them which test to run, when to begin their tests, where to submit reports about the tests and when to shut down.

+ +

A centralized approach has been chosen, using a single coordinator, as test framework code which would otherwise have to be duplicated amongst all the clients will generally be put in the coordinator. The idea is to place as much logic as possible in the coordinator and as little as possible in the clients which means that code will only have to be written and maintained in one place. This code will include code for enlisting clients for tests, deciding which test case to run, and formatting and logging out the results. The alternative would be to have a de-centralized approach, where each client broadcasts the test enlist messages, finds out what other clients are available to talk to, choses which tests to run and outputs the test results. One advantage of the centralized approach, is that the coordinator should know which clients are available, and therefore which clients cannot run particular tests, or fail completely to run particular tests, and should therefore be able to log out failures for clients that fail tests in a more reliable way, than if it were up to the clients to log their own failures and ommissions.

+ +

Build tests out of a standardized construction block.

+ +
    +
  • Diagram: The test circuit.
    • +
+ + +

Publisher/Receiver pair.
+Each end of which is a Producer/Consumer unit.
+ M producers, N consumers, talking over Z destinations.

+ +

One of the stated aima of this specificiation is to "Allow tests to be posed in terms of abstract asynchronous messaging concepts that AMQP and JMS support, rather than at the level of direct interfaces". For example, we know that messages sent in a transaction, must not be delivered until the transaction is committed. This is true of AMQP as it is of JMS; as AMQP is intended to provide similar messaging semantics to JMS. The statement is also true, whether the messages are broadcast to many receivers or sent to just one.

+ +

The standard consruction block for a test, is a test circuit. This consists of a publisher, and a receiver. The publisher and receiver may reside on the same machine, or may be distributed. Will use a standard set of properties to define the desired circuit topology.

+ +

Tests are always to be controlled from the publishing side only. The receiving end of the circuit is to be exposed to the test code through an interface, that abstracts as much as possible the receiving end of the test. The interface exposes a set of 'assertions' that may be applied to the receiving end of the test circuit.

+ +

In the case where the receiving end of the circuit resides on the same JVM, the assertions will call the receivers code locally. Where the receiving end is distributed accross one or more machines, the assertions will be applied to a test report gethered from all of the receivers. Test code will be written to the assertions making as few assumptions as possible about the exact test topology.

+ +

A test circuit defines a test topology, M producers, N consumers, Z outgoing routes between them.
+ The publishing end of each test circuit always resides on a single JVM, even if M > 1. If publishers are to be distributed accross many machines, the test framework itself provides the scaling by running the same test circuit many times in parallel. This means that it is possible to have an arbitrary number of message publishers accross one or many machines, determined by the test setup.
+ The receiving half of the circuit may be local, in which case all messages come back to the same machine, or distributed in which case they may be received by many machines.
+ There are therefore two ways in which tests may be distributed accross multiple nodes in a network; many test circuits may be distributed and run in parallel and/or the receiving ends of those circuits may be distributed or local.
+ Each node in the network can play up to 2 roles in any given test; publisher or receiver. It is possible to play both roles at once, but would like to have a 'single_role' flag, that can be set to ensure that test nodes taking one role, will not participate in the other for the duration of a test. For example, in the pub/sub test want one publisher and the remaining nodes to distribute the receiver role amongst themselves.

+ +

Probing for the available test topology.

+ +
    +
  • Diagram: The available topology.
    • +
+ + +

When the test distribution framework starts up, it should broadcast an 'enlist' request on a known topic. All available nodes in the network to reply in order to make it known that they are available to carry out tests. For the requested test case, C test circuits are to be run in parallel. Each test defines its desired M by N topology for each circuit. The entire network may be available to run both roles, or the test case may have specified a limit on the number of publishing nodes and set the 'single_role' flag. If the number of publishing nodes exhausts the available network and the single role flag is on, then there are no nodes available to run the receiver roles, the test will fail with an error at this point. Suppose there are P nodes available to run the publisher roles, and R nodes available to run the receiver roles. The C test circuits will be divided up as evenly as possible amongst the P nodes. The C * N receivers will be divided up as evenly as possible amongst the R nodes.

+ +

A more concrete example. There are 10 test machines available. Want to run a pub/sub test with 2 publishers, publishing to 50 topics, with 250 subscribers, measuring total throughput. The distribution framework probes to find the ten machines. The test parameters specify a concurrency level of 2 circuits, limited to 2 nodes, with the single role flag set, which leaves 8 nodes to play the receiver role. The test parameters specify each circuit as having 25 topics, unique to the circuit, and 125 receivers. The total of 250 receivers are distributed amongst the 8 available nodes, 31 each, except for two of them which get 32. The test specifies a duration of 10 minutes, sending messages 500 bytes in size using test batches of 10000 messages, as fast as possible. The distribution framework sends a start signal to each of the publishers. The publishers run for 10000 messages. The publishers request a report from each receiver on their cicruit. The receivers send back to the publishers a report on the number of messages received in the batch. The publishers assert that the correct number for the batch were indeed received, and log a time sample for the batch. This continues for 10 minutes. At the end of the 10 minutes, the publishers collate all of their timings, failures, errors into a log message. The distribution framework requests the test report from each publishing nodes, and these logs are combined together to produce a single log for the entire run. Some stats, such as total time taken, total messages through the system, total throughput are calculated and added as a summary to the log, along with a record of the requested and actual topology used to run the test.

+ +
    +
  • Diagram: The requested test applied onto the available topology.
    • +
+ + +

Test Procedures.

+ +

A variety of different tests can be written against a standard test circuit, many of these will follow a common pattern. One of the aims of using a common test circuit configured by a number of test parameters, is to be able to automate the generation of all possible test cases that can be produced from the circuit combined with the common testing pattern, and an outline of a procedure for doing this is described here. The typical test sequence is described below:

+ +

A typical test sequence.

+ +
    +
  1. Initialize the test circuit from the default parameters, plus specific settings for the test.
    2. +
  2. Create the test circuit. The requested test parameters are applied to the available topology to produce a live circuit.
    3. +
  3. Send messages.
    4. +
  4. Request a status report.
    5. +
  5. Assert conditions on the publishing end of the circuit.
    6. +
  6. Assert conditions on the receiving end of the circuit.
    7. +
  7. Pass or fail the test.
    8. +
+ + +

The thorough test procedure.

+ +

The thorough test procedure uses the typical test sequence described above, but generates all of combinations of test parameters and corresponding assertions against the results.

+ +

The all_combinations function produces all combinations of test parameters described in Appendix A.

+ +

all_combinations : List<Properties>

+ +

The expected_results function, produces a list of assertions, given a set of test parameters. For example, mandatory && no_route -> assertions.add(producer.assertMessageReturned), assertions.add(receiver.assertMessageNotReceived).

+ +

expected_results: Properties -> List<Assertions>

+ +

For parameters : all_combinations
+ test_circuit = new TestCircuit(parameters).
+ test_circuit.start.

+ +

Send mesages.
+ Request status.

+ +

For assertion : exected_results(parameters)
+ Assert(assertion).

+ +

Common Requirements.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IOP-3. Directory Structure. All scripts to start and stop brokers and run test clients will be placed in a directory structure underneath a top-level directory called 'interop' that sits at the top level of the Qpid project.
IOP-4. Test Output Format. Output in junit xml format (because a lot of automated build software understands this format). There doesn't seem to be a schema or DTD for this format but it is simple enough. See Appendix B for an example.
IOP-5. Terminate On Timeout. Each client will keep a timeout count. Every time it gets a message it will reset this count. If it does not hear from the broker at all for 60 seconds then it will assume that the broker has died or that the other test clients are failing to communicate with it, and will terminate. Test clients will only wait on this timeout when they are actually expecting messages, for example after enlisting to a test and expecting a role assignment message, or during a test when they are expecting to be sent a test message. If neccessary, this timeout can be extended to a longer time period than 60 secods, its purpose is to ensure eventual termination of all clients during a fully automated build.
IOP-6. Default Virtual Host. All test clients will use the default virtual host (no name) for all tests, unless overriden by test parameters for a particular test case, or by command line options when starting the client.
IOP-7. Broadcast Control Topic. All test clients will listen to control messages broadcast on the routing key 'iop.control' on the default virtual host on the default topic exchange. This control topic is used for communicating with the test coordinator client.
IOP-48. Control Message Replies. All control messages broadcast by the coordinator will include a reply to field. The coordinator will listen on the reply address for responses to its control messages.
IOP-8. No Environment for Scripts. In general, start up scripts should be intelligent enough to configure the environment variables that they need in order to run. It should be sufficient to have a path configured for the neccessary run time tools (such as Java) when calling scripts. Environment variables, such as QPID_HOME, should be set by startup scripts themselves, figured out from their installation locations.
IOP-9. Wait Until Background Process Started. Scripts that start processes running in the background should not terminate until the process they are starting has succesfully started. This is neccessary for reliable testing, to ensure that subsequent scripts can be run, knowing that previous scripts have completed, with dependant proccesses in a known state. For example, it is important to start all test clients prior to starting the coordinator.
+ +

Use Case 1. Starting a Broker.

+ +

Run the broker start script.
+ The script starts a broker running and tries to connect to it (or otherwise ping it) until it is verified to be running.
+ Once the broker is verified to be running the script terminates with no error code.

+ +

Failure path: The broker fails to start or does not appear to be running after a timeout has passed. The script fails with an error code.

+ + + + + + + + + + + + + + + + + +
IOP-10. Broker Start Script. The Java and C++ brokers will define scripts that can start the broker running on the local machine, and these scripts will be located at interop/java/broker/start and interop/cpp/broker/start. The Java and C++ build processes will generate these scripts (or copy pre-defined ones to the output location) as part of their build processes.
IOP-11. Broker Start Failure. If a broker fails to start within 60 seconds its start script will timeout. Script will terminate with error code 1.
IOP-12. Broker Start Succesfull. When the broker starts succesfully the script will terminate with error code 0.
+ +

Use Case 2. Stopping a Broker.

+ +

Run the broker stop script.
+ The script terminates the broker that was started with the start script if it is still running.

+ +

Failure path: The broker won't terminate. The script fails with an error code.

+ + + + + + + + + + + + + + + + + +
IOP-13. Broker Stop Script. The Java and C++ brokers will define scripts that can stop the broker running on the local machine, and these scripts will be located at interop/java/broker/stop and interop/cpp/broker/stop. The Java and C++ build processes will generate these scripts (or copy pre-defined ones to the output location) as part of their build processes.
IOP-14. Broker Stop Timeout. If a broker fails to terminate within 60 seconds its stop script will timeout. Script will terminate with error code 1.
IOP-15. Broker Stop Succesfull. When the broker stops succesfully the script will terminate with error code 0.
+ +

Use Case 3. Starting a Test Client.

+ +

Run the client start script. The caller will pass in the address of the broker to connect to.
+ The script starts a client running.
+ The client starts running but waits for further instruction before running its tests.
+ The start script will terminate but leave the client running as a forked process.

+ +

Failure path: The client will not start, or fails to connect to the specified broker. The script will terminate with error code 1.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IOP-16. Client Start Scripts. For each client implementation, <client>, there will be a start script located at interop/<client>/client/start. The build processes for each client will generate these scripts and output them to this location as part of their build process.
IOP-17. Client Start Timeout. If the client fails to start and connect to the specified broker within 60 seconds the script will terminate with error code 1.
IOP-18. Client Start Succesfull. When the client starts successfully its script will terminate with error code 0.
IOP-19. Client Start Broker and Port. The -b <hostname> option will be used to instruct the start script to connect to the specified hostname. The -p <port> option will similarly allow the port to be specified.
IOP-20. Client Virtual Host. The default virtual host to connect to, may be overridden with the -v <virtual_host> command line option, which will be accepted by all test clients.
IOP-21. Client Start General Parameters. General parameters may be passed to the client start scripts using the synax name=value. These name/value pairs may be used by specific test cases to override default test parameters. See Appendix C for a list of test parameters.
+ +

Use Case 4. Starting the Coordinator.

+ +
    +
  • The requirements defined for Use Case 3, also apply to this use case.
    • +
+ + +

Run the testall start script. The caller will pass in the address of the broker to connect to.
+ The script starts the coordinator client running.
+ The coordinator will manage the test procedure.
+ The scipt will terminate when the coordinator has completed.

+ +

Failure path: The coordinator will not start, or fails to connect to the broker. The script will terminate with error code 1.

+ + + + + + + +
IOP-22. Coordinator Test Script. There will be a coordinator test script that kicks off the testing process once all clients have been started. It is to be located at interop/testall. It will start a coordinator test client that issues test invites, assigns roles, collects results and terminates test clients when all tests have been run.
+ +

Use Case 5. Overall Test Procedure.

+ +

Start a broker running using its start script as described by Use Case 1.
+ Call the start all clients script on each of the machines where there are clients that are to be tested. The caller will pass in address of the broker to connect to, and any additional parameters.
+ The start all script will scan for all start scripts located under interop/<client>/client/start and call each of them forwarding its command line arguments on the call. This performs Use Case 3 for each client.
+ Call the coordinator test client script. This is described as Use Case 4.

+ +

The coordinator test script will broadcast an invite message, with no test name on the control topic. The lack of a test name indicates that this is a compulsory invite, to which all clients must enlist.
+ Each client will respond with an enlist message. This message will contain the routing key on the default topic exchange to which the client has bound its private control queue.
+ The coordinator retains the list of available clients, and the addresses of their control queues.

+ +

The coordinator will broadcast an invite to a named test. This invite may also contain any parameters needed to configure the test, that are relevant to a clients choice to accept the invite or not.
+ All clients that are able to participate in this test will reply to the invite with enlist messages. Clients may opt to participate in the test depending on the test parameters, if desired.
+ The coordinator will send messages to assign roles to the sender and receivers private control topics. These messages will contain the test parameters and roles. The test parameters may also include additional parameters not in the original invite, for test parameters that are to be set on a per test instance basis.
+ The clients will respond with accept role messages.
+ The coordinator will wait until it has received acceptances from both roles.
+ The coordinator will issue a start message to the client with the sender role.
+ The sender client will send its test messages. Once the test has completed the sender will send a report message to the coordinator, giving details about the message that it sent.
+ The coordinator will wait until it receives a report message from the sender.
+ The coordinator will issue a status request message to the reciever role.
+ The receiver will reply with a report, giving details about the messages it has received.
+ The coordinator will wait until it receives a report message from the receiver.
+ The coordinator will compare the sender and receiver reports in order to decide whether the test passed or failed.
+ The coordinator will check its list of available clients and log out failures for any combinations of clients that were not tested because they did not enlist for the test.

+ +

Once all test cases are complete, the coordinator will broadcast a shutdown message.
+ All clients will terminate on receipt of the shutdown message.
+ The coordinator will terminate.
+ Terminate the broker using its stop script.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IOP-23. Start All Script. There will be a start all clients script, located at interop/startall. The startall script finds all client starts scripts under interop/<client>/client/start and calls them.
IOP-24. Start All Script Options Forwarding. The start all script will take the same command line options as the client start scripts and will pass these command line options on to them.
IOP-25. Invite Message.

For every test case the coordinator will broadcast an invite message on the control topic. This message will be identified by the header field, "CONTROL_TYPE", having the value, "INVITE". This message will also include the name of the test case and may also include some test parameters. (See IOP-48, for the reply to address.)

+
+
          "CONTROL_TYPE",               "INVITE"
+          "TEST_NAME",                  "<test_case>"
+          ... optional test parameters.
+
+
IOP-26. Initial Invite. At the start of the test procedure the coordinator will broadcast a compulsory invite, to which all available clients must enlist, in order to declare their availability and to enable the coordinator to detect when there are clients that did not participate in some tests. The compulsory invite will be differentiated form an ordinatory invite because it will have no "TEST_NAME" header field.
IOP-27. Enlist Message.

Every test client that receives an invite message will respond by declaring its availability to run interop tests. The client will send an enlist message by replying to the invite message. The enlist message will be identified by the header field, "CONTROL_TYPE", having the value, "ENLIST". The client will declare the routing key on which it expects to be sent private control messages. The client will also declare a unique name by which it can be identified (see IOP-35). The declare available message will contain the following header fields with this information:

+
+
          "CONTROL_TYPE",               "ENLIST"
+          "CLIENT_NAME",                "<client_name>"             (see IOP-35 for rules about the client name).
+          "CLIENT_PRIVATE_CONTROL_KEY", "iop.control.<client_name>" (see IOP-36)
+
+
IOP-28. Assign Role Message.

Having selected clients to participate in a particular test case, the coordinator will send those clients messages to assign the roles they will play in the test case, on the clients private control topics. Each test case has sender and receiver roles. This message will be identified by the header field, "CONTROL_TYPE", having the value, "ASSIGN_ROLE". The full test parameters will be included in this message, allowing tests to be configured on a per test instance basis.

+
+
          "CONTROL_TYPE",               "ASSIGN_ROLE"
+          ... full test parameters.
+
+
IOP-29. Accept Role Message.

A client receiving an assign role message, will reply to it with an accept role message. This message also indicates that the client is ready to start the test. This message will be identifier by the header field, "CONTROL_TYPE", having the value, "ACCEPT_ROLE".

+
+
          "CONTROL_TYPE",               "ACCEPT_ROLE"
+
+
IOP-30. Start Message.

The coordinator will send a start message to begin the test procedure. All test clients will listen for this message on their private control topics. The start message will be identified by the header field, "CONTROL_TYPE", having the value, "START".

+
+
          "CONTROL_TYPE",               "START"
+
+
IOP-31. Report Message.

Once the test clients have completed a test case, they will send the coordinator a report about the actions they have performed. In the case of senders, this report will be sent once they have finished sending test messages. In the case of receiver, this report will be sent in response to a status request from the coordinator (see IOP-49). The report message will be identified by the header field, "CONTROL_TYPE", having the value, "REPORT". Its message body, or additional header fields will contain the report, specific to the test case being run.

+
+
          "CONTROL_TYPE",               "REPORT"
+          ... test specific parameters.
+          Message body,                 Test case specific report.
+
+
IOP-49. Status Request Message.

Once the coordinator has received the senders report, it will send a status request to the receiver, to request the receivers report. This message will be identified by the header field, "CONTROL_TYPE", having the value, "STATUS_REQUEST".

+
+
          "CONTROL_TYPE",               "STATUS_REQUEST"
+
+
IOP-34. Terminate Message.

The coordinator will wait for all test clients to complete their tests for all test cases at which time it will broadcast a terminate message to the control topic. The terminate message will be identified by the header field, "CONTROL_TOPIC", having the value, "TERMINATE". Upon receipt of this message the test clients will terminate.

+
+
          "CONTROL_TYPE",               "TERMINATE"
+
+
IOP-35. Client Name. Each test client will provide a unique name for itself that reflects its implementation language and distinguishes it from the other clients. Clients may append an environment identifier onto this name to cater for the case where the same client is used multiple times in an interop test. For example, the same client might be run on two different operating systems, in order to check that it works correctly on both. Example names in this case might be "java-win" and "java-linux".
IOP-36. Private Client Control Topic. Each test client will listen for test control messages directed specifically to it on the default topic exchange. The routing key for these messages will consist of "iop.control." followed by the client name (see IOP-35). A topic exchange is used, rather than a direct exchange, to cater for the situation where multiple instances of a client are run in parallel and tests are to be scaled accross many clients (not currently in scope, see Waiting Room). It also allows a listener to be attached to the default topic exchange to listen to all control messages using a wildcard selector.
IOP-37. Seperate Connection for Control Topic. Test clients should create open a seperate connection to communicate with the control topics on the default topic exchange, to that which they use to perform tests. This is so that a channel level error that results in the closing of a connection during a test, may still allow a client to succesfully send a failure report to the coordinator.
+ +

Common Requirements for Test Cases.

+ +

Test cases that use these requirements mention them in the description of the test case.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
IOP-38. Message Counts. Whenever a test client recieves a message from another test client it will increment the total count of messages received from that client. Test messages will contain the name of the sending client in the header field "CLIENT_NAME", and the count will be held against a combination of that name and the messages correlation id (see IOP-42).
IOP-39. Message Count Reset. Whenever a test client is begining a new test case (when it accepts a role) it will reset its message counts to zero.
IOP-41. Message Count Report Message.

Upon receipt of a status request message, a test client will reply with a report message. The report message will be identified by the header field "CONTROL_TYPE", having the value, "REPORT" (as described by IOP-31). In addition to this, the header field, "MESSAGE_COUNT" will contain the count of messages received since the last reset as a signed 32-bit integer.

+
+
          "CONTROL_TYPE",               "REPORT"
+          "MESSAGE_COUNT",              <count>         (signed 32 bit integer)
+
+
IOP-42. Correlation Id. When sending test messages, clients will identify all messages using a unique correlation id for the test case instance. This will differentiate test messages in a situation where the same client is scaled up to run a test case many times in parallel (not in scope, see Waiting Room).
IOP-43. Test Connections. Test clients will create connections to send test messages on when they are assigned roles. In many cases this will consist of creating a single connection, and a producer or consumer for the test routing key or queue. In some tests, which simulate the activity of many message receivers, multiple connections may be opened.
+ +

Test Case 1. Dummy Run.

+ +

The sending client will not send any test messages at all. It will send a report message on the control topic, declaring that the test has passed.

+ +

The purpose of this test case is to check that clients can interoperate succesfully with the test coordinator and participate in the sequencing of the tests.

+ + + + + + + +
IOP-50. Test Case 1 Name. The "TEST_NAME" field in the test invite (IOP-25) will be "TC1_DummyRun" for this test.
+ +

Test Case 2. Basic P2P Test.

+ +
    +
  • This test case uses requirements IOP-38 to 43 inclusive.
    • +
+ + +

The sending client creates a fresh correlation id, and the entire test case conversation uses this id.
+ The sending client will send the required number of test messages to the test routing key on the default direct exchange.
+ The sending client will send a message count report to the coordinator.
+ In response to a status request from the coordinator, the receiving client will reply with a message count report.
+ The coordinator will compare the messages received to the messages sent and pass or fail the test accordingly.

+ + + + + + + + + + + + + + + + + +
IOP-44. Basic P2P Setup. Prior to assigning roles, the coordinator will bind a queue to the default direct exchange with a routing key, the same as the queue name. It will create a fresh queue and key for every test case instance.
IOP-45. Basic P2P Assign Role Parameters.

In addition to the invite message format defined in IOP-26, the basic p2p test invite will also include the following parameters.

+
+
          "P2P_QUEUE_AND_KEY_NAME",     "<name>"
+          "P2P_NUM_MESSAGES",           <count>  (signed 32 bit int), P2P_NUM_MESSAGES property.
+
+
IOP-51. Test Case 2 Name. The "TEST_NAME" field in the test invite (IOP-25) will be "TC2_BasicP2P" for this test.
+ +

Test Case 3. Basic Pub/Sub Test.

+ +
    +
  • This test case uses requirements IOP-38 to 43 inclusive.
    • +
+ + +

The sending client creates a fresh correlation id, and the entire test case conversation uses this id.
+ The sending client will send the required number of test messages to the test routing key on the default topic exchange.
+ The sending client will send a message count report to the coordinator.
+ In response to a status request from the coordinator, the receiving client will reply with a message count report. This number will be the number of messages sent multiplied by the number of receivers being simulated by the receiving client.
+ The coordinator will compare the messages received to the messages sent and pass or fail the test accordingly.

+ + + + + + + + + + + + + + + + + +
IOP-46. Basic Pub/Sub Setup. Prior to assigning roles, the coordinator will choose a routing key for the test. If will create a fresh key for every test case instance.
IOP-47. Basic Pub/Sub Invite Parameters.

In addition to the invite message format defined in IOP-26, the basic pub/sub test invite will also include the following parameters.

+
+
          "PUBSUB_KEY",                  "<key>"
+          "PUBSUB_NUM_RECEIVERS",        <count> (signed 32 bit int), PUBSUB_NUM_RECEIVERS property.
+          "PUBSUB_NUM_MESSAGES",         <count> (signed 32 bit int), PUBSUB_NUM_MESSAGES property.
+
+
IOP-52. Test Case 3 Name. The "TEST_NAME" field in the test invite (IOP-25) will be "TC3_BasicPubSub" for this test.
+ +

Test Case 4. P2P Test with Different Message Sizes.

+ +
    +
  • This test case uses requirements IOP-38 to 43 inclusive.
    • +
+ + +

The sending client creates a fresh correlation id, and the entire test case conversation uses this id.
+ The sending client will send the required number of test messages to the test routing key on the default direct exchange.
+ The sending client will send a message count report to the coordinator.
+ In response to a status request from the coordinator, the receiving client will reply with a message count report.
+ The coordinator will compare the messages received to the messages sent and pass or fail the test accordingly.
+ The above test cycle will be repeated for each message size to test.

+ + + + + + + + + + + + + + + + + + + + + + +
IOP-53. P2P Message Size Test Setup. Prior to assigning roles, the coordinator will bind a queue to the default direct exchange with a routing key, the same as the queue name. It will create a fresh queue and key for every test case instance.
IOP-54. P2P Message Size Test Assign Role Parameters.

In addition to the invite message format defined in IOP-26, the basic p2p test invite will also include the following parameters.

+
+
          "P2P_QUEUE_AND_KEY_NAME",     "<name>"
+          "P2P_NUM_MESSAGES",           <count>  (signed 32 bit int), P2P_NUM_MESSAGES property.
+          "messageSize",                <count>  (signed 32-bit int).
+
+
IOP-55. P2P Message Size Test Sizes The following values for the message size parameter will be tested: 0K, 63K, 64K, 65K, 127K, 128K, 129K, 255K, 256K, 257K.
IOP-56. Test Case 4 Name. The "TEST_NAME" field in the test invite (IOP-25) will be "TC4_P2PMessageSize" for this test.
+ +

Test Case 5. Pub/Sub Test with Different Message Sizes.

+ +
    +
  • This test case uses requirements IOP-38 to 43 inclusive.
    • +
+ + +

The sending client creates a fresh correlation id, and the entire test case conversation uses this id.
+ The sending client will send the required number of test messages to the test routing key on the default topic exchange.
+ The sending client will send a message count report to the coordinator.
+ In response to a status request from the coordinator, the receiving client will reply with a message count report. This number will be the number of messages sent multiplied by the number of receivers being simulated by the receiving client.
+ The coordinator will compare the messages received to the messages sent and pass or fail the test accordingly.
+ The above test cycle will be repeated for each message size to test.

+ + + + + + + + + + + + + + + + + + + + + + +
IOP-57. Pub/Sub Message Size Test Setup. Prior to assigning roles, the coordinator will choose a routing key for the test. If will create a fresh key for every test case instance.
IOP-58. Pub/Sub Message Size Test Invite Parameters.

In addition to the invite message format defined in IOP-26, the basic pub/sub test invite will also include the following parameters.

+
+
          "PUBSUB_KEY",                 "<key>"
+          "PUBSUB_NUM_RECEIVERS",       <count> (signed 32 bit int), PUBSUB_NUM_RECEIVERS property.
+          "PUBSUB_NUM_MESSAGES",        <count> (signed 32 bit int), PUBSUB_NUM_MESSAGES property.
+          "messageSize",                <count> (signed 32-bit int).
+
+
IOP-59. P2P Message Size Test Sizes The following values for the message size parameter will be tested: 0K, 63K, 64K, 65K, 127K, 128K, 129K, 255K, 256K, 257K.
IOP-60. Test Case 5 Name. The "TEST_NAME" field in the test invite (IOP-25) will be "TC5_PubSubMessageSize" for this test.
+ +

Waiting Room:

+ +

Contains ideas for possible future directions relating to this spec.

+ +

Command processor. Test cases to be written using a command language (perhaps in XML) on top of a common client API. Interpreter for this to be implemented using each client library. Test cases need only be written once and can be run by the interpreters. Command language rich enough to exercise the whole AMQP protocol. May not handle client specific edge cases. Good for ensuring test consistency, but may take a fair amount of time to do.

+ +

How I anticipate this being run as part of a fully automated build. Will try to get a free licence for Anthill Pro 3 as they offer free licences for open source projects. Viewtier Parabuild is another possibility. Anthill Pro runs a central build server that does all its work through build agents that can run on many boxes. It also lets you define build workflows. I imagine running a Unix agent to build the c++, java and python stuff, and a Windows agent for the .net stuff. Will define a workflow that starts a broker on the unix box, then starts all clients built on the unix and windows boxes in parallel, then runs the entire test procedure across all clients, then terminates the broker on the unix box. The agents send back the test results to the central server.

+ +

Full testing of field tables. Make sure that every possible data type is tested and confirmed to encode and decode correctly between all client implementations.

+ +

Testing more of the protocol. Add tests to more fully exercise the complete AMQP protocol.

+ +

Allow scaling of test clients. Each test client should only be run once (in each environment) and they create unique names for themselves. Tests are only run between pairs of single clients, with a single sender and number of receivers defined by the test case (often 1). Clients listen for control messages on topics, and use correlation id's in all tests messages to differentiate themselves, were multiple senders to be active. This has been done deliberately to allow for future expansion of the test framework to allow scaling up of the tests by starting more clients in parallel on the same environment. To do this each client might also create a sequence number, to unqiuely identify itself, as the client names will no longer be unique. Reports from senders will include client name, sequence number and correlation id. Status requests to receivers may specify client name, sequence number and correlation id to get specific reports, or ommit correlation id or sequence number to get a bulk report of all messages with a particular client.

+ +

More sophisticated reporting. Message count reports are fairly minimal. Might also put an entire list of messages send/recieved in a report, in order to check that there were no ommissions or duplicates.

+ +

Appendix A, General Notes:

+ +

Brokers that need to be interop tested: C++ and Java

+ +

Clients that need to be interop tested: C++ , Java, Java 1.4 retrotranslation, C++, .Net 2.0, .Net 1.1, (Mono?), Python, Ruby.

+ +

Appendix B, Example of XML Format for Test Ouput:

+ +

I don't think there is a DTD or schema for this but the XML output from JUnit looks like the example below. This is a convenient choice for the output format from these test results even if the code does not actually use JUnit (or cppunit or nunit) iternally, because automated build servers generally understand and are able to produce test reports from it.

+ +

Example:

+ +
+
<?xml version="1.0" encoding="UTF-8" ?>
+<testsuite errors="0" skipped="0" tests="18" time="0.02" failures="0" name="org.apache.qpid.framing.BasicContentHeaderPropertiesTest">
+  <properties>
+    <property value="Java(TM) 2 Runtime Environment, Standard Edition" name="java.runtime.name"/>
+    ... (there were lots of properties).
+  </properties>
+  <testcase time="0.02" name="testRejectedExecution"/>
+  ... (there were lots of test cases).
+</testsuite>
+
+
+ +

Appendix C, Test Parameters.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
  Possible Values Default Value
Connection properties.   
broker tcp, vm tcp://localhost
vhost   <empty>
username   guest
password   guest
Topology properties.   
max_publishing_node   1
single_role true, false true
Circuit properties. Total: 2^2 = 4 combinations.  
num_publishers   1
num_consumers   1
num_destinations   1
base_out_route_name   ping
base_in_route_name   pong
bind_out_route true, false true
bind_in_route true, false false
consumer_out_active true, false true
consumer_in_active true, false false
JMS flags and options. Total: 2 * 2 * 2 * 6 = 48 combinations.  
transactional true, false false
persistent true, false false
no_local true, false false
ack_mode tx, auto, client, dups_ok, no_ack, pre_ack auto
AMQP/Qpid flags and options. Total: 2^4 = 16 combinations.  
exclusive true, false false
immediate true, false false
mandatory true, false false
durable true, false false
prefetch_size   
header_fields   
Standard test parameters. Total: 3 combinations.  
message_size no_body, one_body, multi_body one_body
num_messages   100
outgoing_rate   
inbound_rate   
timeout   30 seconds
tx_batch_size   100
max_pending_data   
+ +

Total combinations over all test parameters: 4 * 48 * 16 * 3 = 9216 combinations.

+ +

Defaults give an in-VM broker, 1:1 P2P topology, no tx, auto ack, no flags, publisher -> receiver route configured, no return route.

+ +

Appendix D, Command line options.

+ +

IOP-21 states that general parameters can be passed on the command line using name=value syntax. The coordinator understands the following parameters, and will use them to override the default values for the tests. Individual test cases refer to the command line parameter that they take their test parameters from.

+ + + + + + + + + + + + + + + + + + +
Parameter Default
P2P_NUM_MESSAGES 50
PUBSUB_NUM_RECEIVERS 5
PUBSUB_NUM_MESSAGES 10
+ +

Appendix E, Clock Synchronization Algorithm.

+ +

On connection/initialization of the framework, synch clocks between all nodes in the available toplogy. For in vm tests, the clock delta and error will automatically be zero. For throughput measurements, the overall test times will be long enough that the error does not need to be particularly small. For latency measurements, want to get accurate clock synchronization. This should not be too hard to achieve over a quiet local network.

+ +

After determining the list of clients available to conduct tests against, the Coordinator synchronizes the clocks of each in turn. The synchronization is done against one client at a time, at a fairly low messaging rate over the Qpid broker. If needed, a more accurate mechanism, using something like NTP over UDP could be used. Ensure the clock synchronization is captured by an interface, to allow better solutions to be added at a later date. Here is a simple algorithm to get started with:

+ +
    +
  1. Coordinator tells client to synchronize its clock with the coordinators time.
    2. +
  2. Client stamps current local time on a "time request" message and sends to Coordinator.
    3. +
  3. Upon receipt by Coordinator, Coordinator stamps Coordinator-time and returns.
    4. +
  4. Upon receipt by Client, Client subtracts current time from sent time and divides by two to compute latency. It subtracts current time from Coordinator time to determine Client-Coordinator time delta and adds in the half-latency to get the correct clock delta.
    5. +
  5. The first result should immediately be used to update the clock since it will get the local clock into at least the right ballpark.
    6. +
  6. The Client repeats steps 1 through 3, 25 or more times, pausing a few tens of milliseconds each time.
    7. +
  7. The results of the packet receipts are accumulated and sorted in lowest-latency to highest-latency order. The median latency is determined by picking the mid-point sample from this ordered list.
    8. +
  8. All samples above approximately 1 standard-deviation from the median are discarded and the remaining samples are averaged using an arithmetic mean.
    9. +
+ + +

The above algorithm includes broker latency, two network hops each way, plus possible effects of buffering/resends on the TCP protocol. A fairly easy improvement on it might be:

+ +
    +
  1. Coordinator tells client to synchronize its clock with the coordinators time, provides a port/address to synchronize against.
    2. +
  2. Clients sends UDP packets to the Coordinators address and performs the same procedure as outlined above.
    3. +
+ + +

Appendix F, Deleted Requirements:

+ +

Put deleted requirements here, in case they can be re-used.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IOP. Client Start Messages Per Test. The -m <num_messages> option will be used to tell the client how many messages to send per test.
IOP. Client Number of Receivers. For topic testing each client will simulate the behaviour of many clients listening to the same topic. The number of receivers per test client for topic tests will be sepcified by the -r <num_receivers> command line option.
IOP. Client Default P2P Test Direct Key. Each test client will listen for test messages on the default direct exchange. The routing key for these messages will consist of the client name (see IOP-35) followed by ".direct".
IOP. Client Default Pub/Sub Test Direct Key. Each test client will listen for test messages on the default topic exchange. The routing key for these messages will consist of the client name (see IOP-35) followed by ".topic".
IOP. Test Done Message.

Once a test client has completed its role, it will send the coordinator a test done message on the control topic. This message will be identified by the header field, "CONTROL_TYPE", having the value, "TEST_DONE". The client will also post its name in the "CLIENT_NAME" header field.

+
+
          "CONTROL_TYPE",               "TEST_DONE"
+
+
IOP. End Role Message.

Once the coordinator receives a report for a test case, it will send end role messages to the private control topics of all clients participating in the test case. This message will be identified by the header field, "CONTROL_TYPE", having the value, "END_ROLE".

+
+
          "CONTROL_TYPE",               "END_ROLE"
+
+
IOP. Client Status Request Message.

When a test client has completed sending test messages it may request the count of actual messages receieved from the test client to which it sent the messages. The status request message will be send to the receving test clients individual control topic. This message will be identified by the header field, "CONTROL_TYPE", having the value, "STATUS_REQUEST", and will contain the name of the sending client in the header field "CLIENT_NAME".

+
+
          "CONTROL_TYPE",               "STATUS_REQUEST"
+          "CLIENT_NAME",                "<client_name>"
+
+
+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/JDBCStore.html b/documentation/content/xdocs/JDBCStore.html new file mode 100755 index 0000000000..19861362b9 --- /dev/null +++ b/documentation/content/xdocs/JDBCStore.html @@ -0,0 +1,38 @@ + + + Apache Qpid : JDBCStore + + + + + + + + + +
+
+ + Apache Qpid : JDBCStore + +
+
+ This page last changed on Jul 04, 2007 by ritchiem. +
+ +

JDBCStore

+ +

This is a MessageStore that uses a JDBC connection as a backing store for the broker.

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/JMS Compliance.html b/documentation/content/xdocs/JMS Compliance.html new file mode 100755 index 0000000000..7e15d701df --- /dev/null +++ b/documentation/content/xdocs/JMS Compliance.html @@ -0,0 +1,41 @@ + + + Apache Qpid : JMS Compliance + + + + + + + + + +
+
+ + Apache Qpid : JMS Compliance + +
+
+ This page last changed on Dec 07, 2006 by ritchiem. +
+ +

Strickt JMS Compliance

+

By default where AMQP is more flexible than JMS the AMQP option is used. To restrict operation to the JMS 1.1 specification set the system property:

+
+
-Dstrict-jms=true
+
+
+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/JMX Management Console.html b/documentation/content/xdocs/JMX Management Console.html new file mode 100755 index 0000000000..3fd5eb6b7a --- /dev/null +++ b/documentation/content/xdocs/JMX Management Console.html @@ -0,0 +1,64 @@ + + + Apache Qpid : JMX Management Console + + + + + + + + + +
+
+ + Apache Qpid : JMX Management Console + +
+
+ This page last changed on Jul 04, 2007 by ritchiem. +
+ +

JMX Management Console

+ +

Overview

+ +

The current Management console is an eclipse application that communicates with the broker of JMX.

+ + + +
+
+ Attachments: +
+ +
+ + Qpid_using_jconsole.doc (application/msword) +
+ + Qpid_using_jconsole.doc (application/msword) +
+ + Qpid_Management_Console.doc (application/msword) +
+ + Qpid_Management_Console.doc (application/msword) +
+ + Qpid_Management_Console.doc (application/msword) +
+
+ +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/JMX Management Console_attachments/Qpid_Management_Console.doc b/documentation/content/xdocs/JMX Management Console_attachments/Qpid_Management_Console.doc new file mode 100755 index 0000000000..245f171d2f Binary files /dev/null and b/documentation/content/xdocs/JMX Management Console_attachments/Qpid_Management_Console.doc differ diff --git a/documentation/content/xdocs/JMX Management Console_attachments/Qpid_using_jconsole.doc b/documentation/content/xdocs/JMX Management Console_attachments/Qpid_using_jconsole.doc new file mode 100755 index 0000000000..910e004218 Binary files /dev/null and b/documentation/content/xdocs/JMX Management Console_attachments/Qpid_using_jconsole.doc differ diff --git a/documentation/content/xdocs/Java Architecture Overview.html b/documentation/content/xdocs/Java Architecture Overview.html new file mode 100755 index 0000000000..4328d7d615 --- /dev/null +++ b/documentation/content/xdocs/Java Architecture Overview.html @@ -0,0 +1,46 @@ + + + Apache Qpid : Java Architecture Overview + + + + + + + + + +
+
+ + Apache Qpid : Java Architecture Overview + +
+
+ This page last changed on Dec 14, 2007 by ritchiem. +
+ +

+ +
+
+ Attachments: +
+ +
+ + Qpid-architecture.png (image/png) +
+
+ +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Java Architecture Overview_attachments/Qpid-architecture.png b/documentation/content/xdocs/Java Architecture Overview_attachments/Qpid-architecture.png new file mode 100755 index 0000000000..fbf600200f Binary files /dev/null and b/documentation/content/xdocs/Java Architecture Overview_attachments/Qpid-architecture.png differ diff --git a/documentation/content/xdocs/Java Broker Design - MessageStore.html b/documentation/content/xdocs/Java Broker Design - MessageStore.html new file mode 100755 index 0000000000..01e45bd524 --- /dev/null +++ b/documentation/content/xdocs/Java Broker Design - MessageStore.html @@ -0,0 +1,39 @@ + + + Apache Qpid : Java Broker Design - MessageStore + + + + + + + + + +
+
+ + Apache Qpid : Java Broker Design - MessageStore + +
+
+ This page last changed on Jul 04, 2007 by ritchiem. +
+ +

The MessageStore interface allows us to abstract the method by which the message data is stored within the broker.

+ +

Currently available implementations

+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Java Coding Standards.html b/documentation/content/xdocs/Java Coding Standards.html new file mode 100755 index 0000000000..e8a81e171b --- /dev/null +++ b/documentation/content/xdocs/Java Coding Standards.html @@ -0,0 +1,406 @@ + + + Apache Qpid : Java Coding Standards + + + + + + + + + +
+
+ + Apache Qpid : Java Coding Standards + +
+
+ This page last changed on Oct 19, 2006 by rgreig. +
+ +

This page documents the standard adopted for Java code in the Qpid project. All committers are expected to follow these standards; checkstyle or similar is used to check compliance.

+ +

Executive Summary

+ +

The main things for layout purposes in the standard are:

+ +
    +
  • Indent using four spaces. No tabs.
    • +
  • braces always go on new lines, e.g.
    • +
+ + +
+
if (x == 5)
+{
+    System.out.println("Hello");
+}
+
+ +

rather than

+
+
if (x == 5} {
+    System.out.println("Hello");
+}
+
+
    +
  • Always add braces, e.g. +
    +
    if (x == 5)
+{
+    System.out.println("Hello");
+}
    +
    • +
+ + +

rather than

+
+
if (x == 5}
+    System.out.println("Hello");
+
+
    +
  • Fields prefixed with underscores, e.g. _messageCount
    • +
  • Spaces after keywords but no spaces either before or after parentheses in method calls, e.g. +
    +
    if (x == 5)
    +
    +

    rather than

    +
    +
    if(x==5)
    +
    +

    but

    +
    +
    foo.bar(4, 5)
    +
    +

    rather than

    +
    +
    foo.bar( 4, 5 )
    +
    • +
+ + +

Details

+ +

Introduction

+ +

This document describes two types of coding standard:

+ +

1. Mandatory standards must be followed at all times.
+2. Recommended standards should in general be followed but in particular cases may be omitted where the programmer feels that there is a good reason to do so.

+ +

Code that does not adhere to mandatory standards will not pass the automated checks (or a code review if the guideline is not stylistic).

+ +

Source files

+

This section defines the general rules associated with the contents of a Java source file and the order in which the each part should be presented. No rules on programming style, naming conventions or indentation are given here.

+ +
    +
  1. Java source files must have a ".java" suffix (this will be enforced by the compiler) [mandatory].
    2. +
  2. The basename of a Java source file must be the same as the public class defined therein (this will be enforced by the compiler) [mandatory].
    3. +
  3. Only one class should be defined per source file (except for inner classes and one-shot uses where the non-public class cannot conceivably be used outside of its context) [mandatory].
    4. +
  4. Source files should not exceed 1500 lines [recommended].
    5. +
  5. No line in a source file should exceed 120 characters [mandatory].
    6. +
  6. The sections of a source file should be presented in the following order [mandatory]:
    7. +
+
    +
  • File information comment (see rule 7 below).
    • +
  • Package name (see rules 1 to 3 in the section 2.1 above and rule 8 below).
    • +
  • Imports (see rules 9 to 10 below).
    • +
  • Other class definitions.
    • +
  • Public class definition.
    • +
+
    +
  1. Do not use automatically expanded log or revision number provided by your source code management system unless it provides a facility to avoid "false conflicts" when doing merges due simply to revision number changes (which happens, for example, with cvs when branches are used). [mandatory]
    2. +
  2. Every class that is to be released must be a member of a package [mandatory].
    +Rationale: classes that are not explicitly put in a package are placed in the unnamed package by the compiler. Therefore as the classes from many developers will be being placed in the same package the likelihood of a name clash is greatly increased.
    3. +
  3. All class imports from the same package should be grouped together. A single blank line should separate imports from different packages [recommended].
    4. +
  4. Use javadoc tags and use HTML mark-up to enhance the readability of the output files [mandatory].
    5. +
+ + +

Java Elements

+

This section gives advice on coding the various elements of the Java programming language.

+

Class definitions

+

This section gives guidelines for class and interface definitions in Java. The term class in this section is used more broadly to mean class and interface:

+
    +
  1. Class names should start with a capital letter with every subsequent word capitalised, for example: DataProcessor [mandatory].
    2. +
  2. The name of exception classes should end in the word exception, for example: UnknownMungeException [mandatory].
    3. +
  3. Class names should in general not be overloaded. For example, defining a class "com.foo.bar.String" should be avoided as there is already a class "java.lang.String" [recommended].
    +Rationale: adhering to this rule reduces the likelihood of confusion and means that the use of fully qualified class names should not be required.
    4. +
  4. The definition of the primary class (i.e. the class with the same name as the java file) should start in column 0 of the source file. Inner class definitions should be indented 4 spaces more than their enclosing class [mandatory].
    5. +
  5. Declare a class as final only if specialisation will never be required and improved performance is essential. With modern JVMs there in fact may be no performance advantage. Warning: use of final limits code reuse [mandatory].
    6. +
  6. For all but simplest classes the following methods should have useful definitions [recommended]: +
    +
    public boolean equals(Object obj)
+public int hashCode()
+public String toString()
    +
    7. +
  7. The order of presentation of the sections in a class should be [mandatory]:
    8. +
+
    +
  • Variables
    • +
  • Methods +

    Variables

    +

    This section gives guidelines for class and instance variable definitions in Java. In this section if a rule uses the term variable rather than instance variable or class variable, then the rule applies to both types of variable.

    • +
+
    +
  1. The order of presentation of variables in a class definition should be [recommended]:
    2. +
+
    +
  • private, protected, public: static final variables (aka constant class variables).
    • +
  • private, protected, public: static variables (aka class variables).
    • +
  • private, protected, public: final variables (aka constant instance variables).
    • +
  • private, protected, public: variables (aka instance variables).
    +It should be noted that as javadoc will automatically order variables in a consistent manner, rigid adherence to this rule is not necessary.
    • +
+
    +
  1. Variable modifiers should be presented in the following order: static, final, transient, volatile [mandatory].
    2. +
  2. The names of static final variables should be upper case with subsequent words prefixed with an underscore [mandatory]. For example: +
    +
    public static final int NOT_FOUND = -1;
    +
    3. +
  3. When a subclass refers to a static final variable defined in a parent class, access should be qualified by specifying the defining class name [mandatory]. For example: use ParentClass.MAX rather than MAX.
    4. +
  4. The names of variables (other that static final) should start with a lower case letter. Any words that are contained in the rest of the variable name should be capitalised [mandatory]. For example: +
    +
    String name;
+String[] childrensNames;
    +
    5. +
  5. Class and instance variables must be prefixed with an underscore (_) [mandatory].
    6. +
  6. Variables must not be named using the so-called Hungarian notation [mandatory]. For example: +
    +
    int nCount = 4; // not allowed
    +
    7. +
  7. Only one variable may be defined per line [mandatory].
    8. +
  8. Variable declarations should be indented 4 spaces more than their enclosing class [mandatory].
    9. +
  9. All variables should be preceded by a javadoc comment that specifies what the variable is for, where it is used and so forth. The comment should be of the following form and be indented to the same level as the variable it refers to [mandatory]
    10. +
  10. Never declare instance variables as public unless the class is effectively a "struct" [mandatory].
    11. +
  11. Never give a variable the same name as a variable in a superclass [mandatory].
    12. +
  12. Ensure that all non-private class variables have sensible values even if no instances have been created (use static initialisers if necessary, i.e. "static { ... }") [mandatory].
    +Rationale: prevents other objects accessing fields with undefined/unexpected values. +

    Methods

    +

    This section gives guidelines for class and instance method definitions in Java. In this section if a rule uses the term method rather than instance method or class method, then the rule applies to both types of method.

    13. +
  13. Constructors and finalize methods should follow immediately after the variable declarations [mandatory].
    14. +
  14. Do not call non-final methods from constructors. This can lead to unexpected results when the class is subclassed. If you must call non-final methods from constructors, document this in the constructor's javadoc [mandatory]. Note that private implies final.
    15. +
  15. Methods that are associated with the same area of functionality should be physically close to one another [recommended].
    16. +
  16. After grouping by functionality, methods should be presented in the following order [recommended]:
    17. +
+
    +
  • private, protected, public: static methods.
    • +
  • private, protected, public: instance methods.
    +It should be noted that as javadoc will automatically order methods in a consistent manner, rigid adherence to this rule is not necessary.
    • +
+
    +
  1. Method modifiers should be presented in the following order: abstract, static, final., synchronized [mandatory]
    2. +
  2. When a synchronized method is overloaded, it should be explicitly synchronized in the subclass [recommended].
    3. +
  3. Method names should start with a lower case letter with all subsequent words being capitalised [mandatory]. For example: +
    +
    protected int resize(int newSize)
+protected void addContentsTo(Container destinationContainer)
    +
    4. +
  4. Methods which get and set values should be named as follows [mandatory]: +
    +
    Type getVariableName()
+void setVariableName(Type newValue)
    +
    +

    Exceptions should be used to report any failure to get or set a value. The "@param" description should detail any assumptions made by the implementation, for example: "Specifying a null value will cause an error to be reported".

    5. +
  5. Method definitions should be indented 4 spaces more than their enclosing class [mandatory].
    6. +
  6. All methods should be preceded by a javadoc comment specifying what the method is for, detailing all arguments, returns and possible exceptions. This comment should be of the following form and be indented to the same level as the method it refers to [mandatory]:
    7. +
  7. The braces associated with a method should be on a line on their own and be indented to the same level as the method [mandatory]. For example: +
    +
    public void munge()
+{
+    int i;
+    // method definition omitted...
+}
    +
    8. +
  8. The body of a method should be indented 4 columns further that the opening and closing braces associated with it [mandatory]. See the above rule for an example.
    9. +
  9. When declaring and calling methods there should be no white space before or after the parenthesis [mandatory].
    10. +
  10. In argument lists there should be no white space before a comma, and only a single space (or newline) after it [mandatory]. For example: +
    +
    public void munge(int depth, String name)
+{
+    if (depth > 0)
+    {
+        munge(depth - 1, name);
+    }
+    // do something
+}
    +
    11. +
  11. Wherever reasonable define a default constructor (i.e. one that takes no arguments) so that Class.newInstance() may be used [recommended]. If an instance which was created by default construction could be used until further initialisation has been performed, then all unserviceable requests should cause a runtime exception to be thrown.
    12. +
  12. The method public static void main() should not be used for test purposes. Instead a test/demo program should be supplied separately. [mandatory].
    13. +
  13. Public access methods (i.e. methods that get and set attributes) should only be supplied when required [mandatory].
    14. +
  14. If an instance method has no natural return value, declare it as void rather than using the "return this;" convention [mandatory].
    15. +
  15. Ensure that non-private static methods behave sensibly if no instances of the defining class have been created [mandatory]. +

    Expressions

    +

    This section defines the rules to be used for Java expressions:

    16. +
  16. Unary operators should not be separated from their operand by white space [mandatory].
    17. +
  17. Embedded ++ or – operators should only be used when it improves code clarity [recommended]. This is rare.
    18. +
  18. Extra parenthesis should be used in expressions to improve their clarity [recommended].
    19. +
  19. The logical expression operand of the "?:" (ternary) operator must be enclosed in parenthesis. If the other operands are also expressions then they should also be enclosed in parenthesis [mandatory]. For example: +
    +
    biggest = (a > b) ? a : b;
+complex = (a + b > 100) ? (100 * c) : (10 * d);
    +
    20. +
  20. Nested "?:" (ternary) operators can be confusing and should be avoided [mandatory].
    21. +
  21. Use of the binary "," operator (the comma operator) should be avoided [mandatory]. Putting all the work of a for loop on a single line is not a sign of great wisdom and talent.
    22. +
  22. If an expression is too long for a line (i.e. extends beyond column 119) then it should be split after the lowest precedence operator near the break [mandatory]. For example: +
    +
    if ((state == NEED_TO_REPLY) ||
+    (state == REPLY_ACK_TIMEOUT))
+{
+    // (re)send the reply and enter state WAITING_FOR_REPLY_ACK
+}
    +
    +

    Furthermore if an expression requires to be split more than once, then the split should occur at the same logical level if possible.

    23. +
  23. All binary and ternary operators (exception for ".") should be separated from their operands by a space [mandatory]. +

    Statements

    +
    Simple Statements
    +

    This section defines the general rules for simple Java statements:

    24. +
  24. There must only be one statement per line [mandatory].
    25. +
  25. In general local variables should be named in a similar manner to instance variables [recommended].
    26. +
  26. More than one temporary variable may be declared on a single line provided no initialisers are used [mandatory]. For example: +
    +
    int j, k = 10, l;  // Incorrect!
+int j, l;          // Correct
+int k = 10;
    +
    27. +
  27. A null body for a while, for, if, etc. should be documented so that it is clearly intentional [mandatory].
    28. +
  28. Keywords that are followed by a parenthesised expression (such as while, if, etc) should be separated from the open bracket by a single space [mandatory]. For example: +
    +
    if (a > b)
+{
+    munge();
+}
    +
    29. +
  29. In method calls, there should be no spaces before or after the parentheses [mandatory]. For example: +
    +
    munge (a, 10);    // Incorrect!
+munge(a, 10);     // Correct.
    +
    +
    Compound Statements
    +

    This section defines the general rules associated with compound statements in Java:

    30. +
  30. The body of a compound statement should be indented by 4 spaces more than the enclosing braces [mandatory]. See the following rule for an example.
    31. +
  31. The braces associated with a compound statement should be on their own line and be indented to the same level as the surrounding code [mandatory]. For example: +
    +
    if ((length >= LEN_BOX) && (width >= WID_BOX))
+{
+    int i;
+    // Statements omitted...
+}
    +
    32. +
  32. If the opening and closing braces associated with a compound statement are further than 20 lines apart then the closing brace should annotated as follows [mandatory]: +
    +
    for (int j = 0; j < SIZE; j++)
+{
+    lotsOfCode();
+} // end for
    +
    33. +
  33. All statements associated with an if or if-else statement should be made compound by the use of braces [mandatory]. For example: +
    +
    if (a > b)
+{
+    statement();
+}
+else
+{
+    statement1();
+    statement2();
+}
    +
    34. +
  34. The case labels in a switch statement should be on their own line and indented by a further 4 spaces. The statements associated with the label should be indented by 4 columns more than the label and not be enclosed in a compound statement. [mandatory]. For example: +
    +
    switch (tState)
+{
+    case NOT_RUNNING:
+        start();
+        break;
+
+    case RUNNING:
+    default:
+        monitor();
+        break;
+}
    +
    35. +
  35. In switch statements - the statements associated with all cases should terminate with a statement which explicitly determines the flow of control, for example break [recommended].
    36. +
  36. In switch statements - fall through should be avoided wherever possible, however if it is unavoidable it must be commented with "// FALLTHROUGH" [mandatory].
    37. +
  37. In switch statements - a default case must be present and should always be the last case [mandatory]. +

    General

    +

    This section gives general rules to be followed when programming in Java:

    38. +
  38. When comparing objects for equivalence use the method equals() and not the == operator. The only exceptions to this are static final objects that are being used as constants and interned Strings [mandatory].
    39. +
  39. In general labelled break and continue statements should be avoided [recommended]. This is due to the complex flow of control, especially when used with try/finally blocks.
    40. +
  40. Unless some aspect of an algorithm relies on it, then loops count forward [mandatory]. For example: +
    +
    for (int j = 0; j < size; j++)
+{
+    // Do something interesting
+}
    +
    41. +
  41. Use local variables in loops [recommended]. For example: +
    +
    ArrayList clone = (ArrayList)listeners.clone();
+final int size = clone.size();
+for (int j = 0; j < size; j++)
+{
+    System.out.println(clone.elementAt(j));
+}
    +
    42. +
  42. Anonymous inner classes should define no instance variables and be limited to three single line methods. Inner classes that declare instance variables or have more complex methods should be named [mandatory].
    43. +
  43. Use final local variables where possible to help avoid errors in code [recommended]. For example: +
    +
    public void foo()
+{
+    final int x = dataSource.getCount();
+    // do things with x
+    // ...
+}
    +
    +

    Exceptions

    +

    This section gives general guidance on the use of exceptions when programming in Java.

    44. +
  44. try/catch blocks should be laid out like any other compound statement [mandatory]. For example: +
    +
    try
+{
+    String str = someStrings[specifiedIndex];
+}
+catch (IndexOutOfBoundsException ex)
+{
+    // The user specified an incorrect index, better take
+    // some remedial action.
+}
    +
    +

    4. When an exception is caught but ignored then a comment should be supplied explaining the rationale [mandatory]. For example:

    +
    +
    try
+{
+    propertySet.setProperty("thingy", new Integer(10));
+}
+catch (UnknownPropertyException ignore)
+{
+    // This exception will never occur as "thingy" definitely exists
+}
    +
    45. +
  45. All exceptions that are likely to be thrown by a method should be documented, except if they are runtime exceptions (note: the compiler will not enforce catch blocks for runtimes even if they are mentioned in the throws clause) [mandatory]. For example: +
    +
    /* Comment snippet:
+ * @exception IllegalValueException Thrown if values is null or 
+ *     any of the integers it contains is null.
+ */
+private Integer sum(Integer[] values) throws IllegalValueException
    +
    46. +
+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Java Unit Tests with InVM Broker.html b/documentation/content/xdocs/Java Unit Tests with InVM Broker.html new file mode 100755 index 0000000000..ec5f9191e6 --- /dev/null +++ b/documentation/content/xdocs/Java Unit Tests with InVM Broker.html @@ -0,0 +1,84 @@ + + + Apache Qpid : Java Unit Tests with InVM Broker + + + + + + + + + +
+
+ + Apache Qpid : Java Unit Tests with InVM Broker + +
+
+ This page last changed on Mar 28, 2008 by godfrer. +
+ +

Sample Code

+ +

Here is a template for correctly creating a unit test that will use the InVM Broker.

+ +
+
+    @Before
+    public void initialSetup() throws Exception
+    {
+        createVMBroker();
+
+        //Any other setup code 
+
+    }
+
+    public void createVMBroker()
+    {
+        try
+        {
+            TransportConnection.createVMBroker(1);
+            // Multiple Brokers can be created by passing in a different port. The above is connected to with the url vm://:1
+        }
+        catch (AMQVMBrokerCreationException e)
+        {
+            Assert.fail("Unable to create broker: " + e);
+        }
+    }
+
+    @After
+    public void stopVmBroker()
+    {
+        // If you created a connection in the @Before be sure to close it before you kill the broker or 
+        //  it will attempt failover, and recreate the broker.
+        TransportConnection.killVMBroker(1);
+        //Remember to kill any other brokers you create
+    }
+
+    @Test
+    public void yourTest code() throws Exception
+    {
+        //If you do your connection setup here
+        Connection con = new AMQConnection("vm://:1", "guest", "guest", "consumer1", "test");
+
+
+        // Be sure to close it before you end the test
+        con.close();
+    }
+
+
+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/License.html b/documentation/content/xdocs/License.html new file mode 100755 index 0000000000..5165d80991 --- /dev/null +++ b/documentation/content/xdocs/License.html @@ -0,0 +1,100 @@ + + + Apache Qpid : License + + + + + + + + + +
+
+ + Apache Qpid : License + +
+
+ This page last changed on Apr 11, 2008 by cctrieloff. +
+ +

Qpid is licensed in under the ASL 2.0. Please look at the notice files provided with the downloads to see the list of embedded components.

+
+

Apache License
+ Version 2.0, January 2004
+http://www.apache.org/licenses/
+ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

+ +

1. Definitions.

+ +

"License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document.

+ +

"Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.

+ +

"Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means ( i ) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.

+ +

"You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License.

+ +

"Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.

+ +

"Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.

+ +

"Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).

+ +

"Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.

+ +

"Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution."

+ +

"Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.

+ +

2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.

+ +

3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

+ +

4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:

+
    +
  1. You must give any other recipients of the Work or Derivative Works a copy of this License; and
    2. +
+ + +
    +
  1. You must cause any modified files to carry prominent notices stating that You changed the files; and
    2. +
+ + +
    +
  1. You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and
    2. +
+ + +
    +
  1. If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.
    2. +
+ + +

You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.
+5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.

+ +

6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.

+ +

7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.

+ +

8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.

+ +

9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.

+
+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Low-Level API Diagram.html b/documentation/content/xdocs/Low-Level API Diagram.html new file mode 100755 index 0000000000..0ae6033ae6 --- /dev/null +++ b/documentation/content/xdocs/Low-Level API Diagram.html @@ -0,0 +1,46 @@ + + + Apache Qpid : Low-Level API Diagram + + + + + + + + + +
+
+ + Apache Qpid : Low-Level API Diagram + +
+
+ This page last changed on Aug 22, 2007 by rupertlssmith. +
+ +

+ +
+
+ Attachments: +
+ +
+ + api.GIF (image/gif) +
+
+ +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Low-Level API Diagram_attachments/api.GIF b/documentation/content/xdocs/Low-Level API Diagram_attachments/api.GIF new file mode 100755 index 0000000000..ba9395e961 Binary files /dev/null and b/documentation/content/xdocs/Low-Level API Diagram_attachments/api.GIF differ diff --git a/documentation/content/xdocs/M1 Release Check list.html b/documentation/content/xdocs/M1 Release Check list.html new file mode 100755 index 0000000000..c0034ea8b0 --- /dev/null +++ b/documentation/content/xdocs/M1 Release Check list.html @@ -0,0 +1,97 @@ + + + Apache Qpid : M1 Release Check list + + + + + + + + + +
+
+ + Apache Qpid : M1 Release Check list + +
+
+ This page last changed on Nov 10, 2006 by ritchiem. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Item Description Status
Check license for dependencies Complete MM 10 Nov, required licenses added
Create NOTICE.txt and LICENSE.txt in the root folder Complete QPID-74, QPID-79
Add all attributions to NOTICE.txt Complete MM 10 Nov, required attributions added
Task to create source distribution Complete QPID-74 ant target 'std-src-release'
Task to create binary distribution
 Complete QPID-73 ant target 'std-bin-release'
Proper naming of release artifacts
 Complete QPID-77
Check if all release jars containing a LICENSE.txt and NOTICE.txt
 Complete QPID-78
Proper versioning (adding the correct version numbers to the jar/src files)
 QPID-73 & QPID-74 ?
Check if Subversion tag is created for release
Rajith to action please
Release Notes Complete QPID-79
README doc in the root folder Complete QPID-79
Basic documentation Complete and ref'd in release notes and readme
Keys ready for singing the release Rajith/Gordon to action please QPID-82 pending
Adding minimum JDK version for the client/common (1.4) and broker (1.5) Complete QPID-83
+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/M1 Release.html b/documentation/content/xdocs/M1 Release.html new file mode 100755 index 0000000000..3162adcad4 --- /dev/null +++ b/documentation/content/xdocs/M1 Release.html @@ -0,0 +1,51 @@ + + + Apache Qpid : M1 Release + + + + + + + + + +
+
+ + Apache Qpid : M1 Release + +
+
+ This page last changed on Apr 19, 2007 by mmccorma. +
+ +

M1 Release - COMPLETED 14th Dec 2006

+ +

Target Date - November 2006 (tbc)

+ +

Release Manager - Rajith Attapattu

+ +

Release Notes

+ +

You can view our release notes for M1 at:

+ +

https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12312115&styleName=Html&projectId=12310520

+ +

Release Check list

+

M1 Release Check list

+ +

Supported Feature List

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/M2 - config.xml.html b/documentation/content/xdocs/M2 - config.xml.html new file mode 100644 index 0000000000..bd14dbe439 --- /dev/null +++ b/documentation/content/xdocs/M2 - config.xml.html @@ -0,0 +1,249 @@ + + + Apache Qpid : M2 - config.xml + + + + + + + + + +
+
+ + Apache Qpid : M2 - config.xml + +
+
+ This page last changed on Apr 08, 2008 by ritchiem. +
+ +

M2 Broker config.xml details

+ +

Changes from M1 configuration

+ + +

File Format

+

This is an overview of the top level of the config file. Description of each section is embedded below. Each section is then described in detail in their own section.

+ +
+
<broker>
+<!-- Various initial global definitions -->
+    <connector>
+<!-- Various connection information about the type connections the broker should listen for-->
+    <management>
+<!-- Enablement of management functionality -->
+    <advanced>
+<!-- Various advanced flags -->
+    <security>
+<!-- Definition of available security options -->
+    <virtualhosts>
+<!-- Definition of available virtual hosts -->
+    <heartbeat>
+<!-- Heartbeat configuration -->
+    <queue>
+<!-- General queue configuration options-->
+    <virtualhosts>
+<!-- Configuration of various virtual hosts. -->
+</broker>
+
+
+
+ +

Configuration Sections - Detailed Information

+ +

The following sections provide an element by element overview of the config.xml.

+ +

Broker

+ +

The setting of the prefixes for QPID_HOME and QPID_WORK allows environment variables to be used throughout the config.xml and removes the need for hard coding of paths in this file.

+ +

See the Getting Started Guide for more information on these variables.

+ +
+
<broker>
+    <prefix>${QPID_HOME}</prefix>
+    <work>${QPID_WORK}</work>
+    <conf>${prefix}/etc</conf>
+
+
+ +

Connector

+ +

The connector section allows configuration of SSL and related keystore settings. By default this section is commented out and thus SSL is not enabled.

+ +
+
<connector>
+    <!-- Uncomment out this block and edit the keystorePath and keystorePassword
+         to enable SSL support
+    <ssl>
+        <enabled>true</enabled>
+        <sslOnly>true</sslOnly>
+        <keystorePath>/path/to/keystore.ks</keystorePath>
+        <keystorePassword>keystorepass</keystorePassword>
+    </ssl>-->
+    <qpidnio>true</qpidnio>
+    <transport>nio</transport>
+    <port>5672</port>
+    <sslport>8672</sslport>
+    <socketReceiveBuffer>32768</socketReceiveBuffer>
+    <socketSendBuffer>32768</socketSendBuffer>
+</connector>
+
+
+ +

Management

+ +

This element allows the user to switch the connectivity of the management console on/off i.e. if the enabled tag is set to false you will not be able to connect a management console to this broker instance.

+ +
+
<management>
+    <enabled>true</enabled>
+</management>
+
+
+ +

Advanced

+

The elements in this section are used under the covers in the broker. At present, we do not recommend any changes to these settings.

+ +
+
<advanced>
+   <filterchain enableExecutorPool="true"/>
+    <enablePooledAllocator>false</enablePooledAllocator>
+    <enableDirectBuffers>false</enableDirectBuffers>
+    <framesize>65535</framesize>
+    <compressBufferOnQueue>false</compressBufferOnQueue>
+</advanced>
+
+
+ +

Security

+ +

This section lists all the principal databases that are available for authentication and the default access control. The databases understand what SASL mechanisms can be used against their data and so are responsible for registering these SASL mechanisms. Currently we do not provide means of limiting these mechanisms.

+
+
<security>
+    <principal-databases>
+        <principal-database>
+            <!-- A name for referencing this database-->
+            <name>passwordfile</name>
+            <!-- The type of principal database -->
+            <class>org.apache.qpid.server.security.auth.database.PlainPasswordVhostFilePrincipalDatabase</class>
+            <!-- Any attributes associated with the database. Here it is a password file to load. -->
+            <attributes>
+                <attribute>
+                    <name>passwordFile</name>
+                    <value>${conf}/passwdVhost</value>
+                </attribute>
+            </attributes>
+        </principal-database>
+    </principal-databases>
+    <!-- This access value can be any access manager. The built in defaults are AllowAll and DenyAll -->
+    <access>
+        <class>org.apache.qpid.server.security.access.AllowAll</class>
+    </access>
+    <!-- Properties required when running the JMX Management console. -->
+    <jmx>
+       <!-- Access file that allows users rights to access the management console. -->
+       <access>${conf}/jmxremote.access</access>
+       <!-- The principal database to use to authenticate users. -->
+       <principal-database>passwordfile</principal-database>
+    </jmx>        
+</security>
+
+
+ +

Virtualhosts

+ +

This section allows you to define the set of virtual hosts which will be contained in your broker instance, and the message store & location for each. NB: The commented out section referencing BDBMessageStore should be used for all applications wishing to use persistence to disk.

+ +

If you are using transient messaging you can use the MemoryMessageStore, with the caveat that scalability for transient use is limited by heap size.

+ +

In our example config.xml, we define three virtual hosts which we commonly use for development (development), system testing (test) and integration testing (localhost). In the config.xml the per virtual host sections define both the Message Store in use (MemoryMessageStore for non-persistent applications or BDBMessageStore for persistent application usage) and the security for each virtual host. The security settings are under currently development so subject to changes.

+ +

The default virtual host for connections which do not specify a host on the url is 'test' in the example config.xml.

+ +
+
<virtualhost>
+            <name>localhost</name>
+            <localhost>
+                <store>
+                    <!-- <class>org.apache.qpid.server.store.berkeleydb.BDBMessageStore</class>
+                    <environment-path>${work}/localhost-store</environment-path> -->
+
+                    <class>org.apache.qpid.server.store.MemoryMessageStore</class>
+                </store>
+
+                <security>
+                    <!-- Need protocol changes to allow this-->
+                    <authentication>
+                        <name>passwordfile</name>
+                        <!-- Currently this can't be used as Vhost isn't specified at connection start only connection open -->
+                        <mechanism>PLAIN</mechanism>
+                    </authentication>
+                    <access>
+                        <class>org.apache.qpid.server.security.access.PrincipalDatabaseAccessManager</class>
+                        <attributes>
+                            <attribute>
+                                <name>principalDatabase</name>
+                                <value>passwordfile</value>
+                            </attribute>
+                            <attribute>
+                                <name>defaultAccessManager</name>
+                                <value>DenyAll</value>
+                            </attribute>
+                        </attributes>
+                    </access>
+                </security>
+            </localhost>
+        </virtualhost>
+
+
+ +

Heartbeat

+ +

The Qpid broker sends an internal (only) heartbeat. This element allows configuration of the frequency of this heartbeat. At present, we recommend that you leave this section unchanged !

+ +
+
<heartbeat>
+    <delay>0</delay>
+    <timeoutFactor>2.0</timeoutFactor>
+</heartbeat>
+
+
+ +

Queue

+ +

This should NOT be changed lightly as it sets the broker up to automatically bind queues to exchanges.

+ +

It could theoretically be used to prevent users creating new queues at runtime, assuming that you have created all queues/topics etc at broker startup. However, best advice is to leave unchanged for now.

+ +
+
<queue>
+    <auto_register>true</auto_register>
+</queue>
+
+
+ +

Virtualhosts

+ +

This element allows you to specify a location for the virtualhosts.xml file that you wish to use. If you are not using a subdirectory under $QPID_HOME you can provide a fully qualified path instead. For more information on the content of the virtualhosts.xml file please see Configure the Virtual Hosts via virtualhosts.xml

+ +
+
<virtualhosts>${conf}/virtualhosts.xml</virtualhosts>
+
+
+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/M2 Release.html b/documentation/content/xdocs/M2 Release.html new file mode 100755 index 0000000000..0d916e0b52 --- /dev/null +++ b/documentation/content/xdocs/M2 Release.html @@ -0,0 +1,112 @@ + + + Apache Qpid : M2 Release + + + + + + + + + +
+
+ + Apache Qpid : M2 Release + +
+
+ This page last changed on Jun 18, 2007 by ritchiem. +
+ +

M2 Release - Overview

+ +

The Qpid project voted to make an M2 release (see this thread) which will include:

+ +

Java Broker (with a caveat on the clustered broker code)
+Java Client
+C++ Broker
+C++ Client
+.NET Client
+Python Client
+Ruby Client

+ +

This will be a significant step up from the M1 Release, which only included the Java components.

+ +

M2 Release Tasks

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Task Status Owner Notes
Identify Release Manager Complete Marnie McCormack Rajith Attapattu volunteered
Identify JIRAs for inclusion in M2 In Progress Marnie McCormack Tidying up M2 tasks to leave only open tasks for release + showstoppers
Define minimal interop requirements for M2 Complete Rupert Smith Interop test suites now exist in Java/C++/.Net. Covers fairly minimal use-cases of basic p2p and pub/sub messaging.
Identify License Issues Not Started ? Aware that there are probably license tidy ups for Java and need to review license list for C++ etc
c++ broker and client owner In progress Rajith Alan volunteered to handle the c++ broker and client release
Python and Ruby client owner In progress Rajith Rafi volunteered to handle the Ruby and Python client release
java broker and client owner In progress Rajith Martin volunteered to handle the Java broker and client release
+ +

C++ Client/Broker Action - Items for M2 release

+ +

C++ JIRAs for M2

+ +

Python & Ruby Clients - Action Items for M2 release

+ + +

Java Client/Broker - Action Items for M2 release

+ +

Java JIRAs for M2

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/M2.1 - config.xml.html b/documentation/content/xdocs/M2.1 - config.xml.html new file mode 100755 index 0000000000..1f8998370b --- /dev/null +++ b/documentation/content/xdocs/M2.1 - config.xml.html @@ -0,0 +1,266 @@ + + + Apache Qpid : M2.1 - config.xml + + + + + + + + + +
+
+ + Apache Qpid : M2.1 - config.xml + +
+
+ This page last changed on Apr 08, 2008 by ritchiem. +
+ +

M2.1 Broker config.xml details

+ +

Qpid Upgrade steps from M2

+ +

Here are the manual changes required to config.xml for M2.1:

+ +

1. Remove use of old password format

+
    +
  • Replace line '<class>org.apache.qpid.server.security.auth.database.PlainPasswordVHostFilePrincipalDatabase</class>'
    • +
  • With '<class>org.apache.qpid.server.security.auth.database.PlainPasswordFilePrincipalDatabase</class>'
    • +
  • Change format of the password file '${conf}/passwdVhost' to be username:password
    • +
  • Rename file on disk '${conf}/passwdVhost' to '${conf}/passwd'
    • +
  • Replace config line '<value>${conf}/passwdVhost</value>' with '<value>${conf}/passwd</value>'
    • +
  • For details on how to configure the new ACLs to restore the per VirtualHost Access rights see Configure ACLs
    • +
+ + +

2. Update package of AllowAll

+
    +
  • Replace line '<class>org.apache.qpid.server.security.access.AllowAll</class>'
    • +
  • With '<class>org.apache.qpid.server.security.access.plugins.AllowAll</class>'
    • +
+ + +

3. Remove all Security sections from virtualhosts

+ + +

Changes from M2 configuration

+ +

There are a four sections with changes that have occurred since M2. Taking them in order as they appear in the file the first change is in the connector section. The protectio feature is new its purpose is to limit the underlying send and receive buffers so that they do not grow unbounded. Testing has shown this feature to affect performance so further work is required to fully understand the impact.

+ +

The advanced section now includes a boolean enableJMSXUserID which causes the broker to stamp every message with the UserID of the producing connection. This has an impact on performance so will be improved in a later release with client side setting of JMSXUserID and broker side verification, which is a low overhead.

+ +

The security section has had a couple of changes. The PlainPasswordVHostFilePrincipalDatabase was an early attempt to show how ACLs could be performed. The introduction of a more comprehensive ACL package now removes the need for that class and so the use of PlainPasswordFilePrincipalDatabase would be recommended instead. The change to ACLs also included the repackaging of the AllowAll ACL class to be in a pluings package.

+ +

The virtualhost sections now have new security sections based on the type of ACL being used. The documentation of which will occur on the a different page.

+ + +

File Format

+

This is an overview of the top level of the config file. Description of each section is embedded below. Each section is then described in detail in their own section. Each section that has changes from M2 is highlighted.

+ +
+
<broker>
+    <connector>
+<!-- Type of connections and properties -->                      <!-- Additional features in M2.1 -->
+    <management>
+<!-- Enablement of management functionality -->
+    <advanced>
+<!-- Various advanced flags -->                                  <!-- Additional features in M2.1 -->  
+    <security>
+<!-- Definition of available security options -->                <!-- M2 Incompatible changes in M2.1 -->
+    <virtualhosts>
+<!-- Definition of available virtual hosts -->                   <!-- M2 Incompatible changes in M2.1 -->
+    <heartbeat>
+<!-- Heartbeat configuration -->
+    <queue>
+<!-- General queue configuration options-->
+    <virtualhosts>
+<!-- Configuration of various virtual hosts. -->
+</broker>
+
+
+
+ +

Configuration Sections - Detailed Information

+ +

The following sections provide an element by element overview of the config.xml.

+ +

Broker

+ +

The setting of the prefixes for QPID_HOME and QPID_WORK allows environment variables to be used throughout the config.xml and removes the need for hard coding of paths in this file.

+ +

See the Getting Started Guide for more information on these variables.

+ +
+
<broker>
+    <prefix>${QPID_HOME}</prefix>
+    <work>${QPID_WORK}</work>
+    <conf>${prefix}/etc</conf>
+
+
+ +

Connector

+ +

The connector section allows configuration of SSL and related keystore settings. By default this section is commented out and thus SSL is not enabled.

+ +
+
<connector>
+    <!-- Uncomment out this block and edit the keystorePath and keystorePassword
+         to enable SSL support
+    <ssl>
+        <enabled>true</enabled>
+        <sslOnly>true</sslOnly>
+        <keystorePath>/path/to/keystore.ks</keystorePath>
+        <keystorePassword>keystorepass</keystorePassword>
+    </ssl>-->
+    <qpidnio>false</qpidnio>
+    <protectio>                                          <!-- New Feature in M2.1 -->
+       <enabled>false</enabled>
+       <readBufferLimitSize>262144</readBufferLimitSize>
+       <writeBufferLimitSize>262144</writeBufferLimitSize>
+    </protectio>
+    <transport>nio</transport>
+    <port>5672</port>
+    <sslport>8672</sslport>
+    <socketReceiveBuffer>32768</socketReceiveBuffer>
+    <socketSendBuffer>32768</socketSendBuffer>
+</connector>
+
+
+ +

Management

+ +

This element allows the user to switch the connectivity of the management console on/off i.e. if the enabled tag is set to false you will not be able to connect a management console to this broker instance.

+ +
+
<management>
+    <enabled>true</enabled>                                    
+</management>
+
+
+ +

Advanced

+

The elements in this section are used under the covers in the broker. At present, we do not recommend any changes to these settings.

+ +
+
<advanced>
+   <filterchain enableExecutorPool="true"/>
+    <enablePooledAllocator>false</enablePooledAllocator>
+    <enableDirectBuffers>false</enableDirectBuffers>
+    <framesize>65535</framesize>
+    <compressBufferOnQueue>false</compressBufferOnQueue>
+    <enableJMSXUserID>false</enableJMSXUserID>           <!-- Additional features in M2.1 -->
+</advanced>
+
+
+ +

Security

+ +

This section lists all the principal databases that are available for authentication and the default access control. The databases understand what SASL mechanisms can be used against their data and so are responsible for registering these SASL mechanisms. Currently we do not provide means of limiting these mechanisms.

+
+
<security>
+    <principal-databases>
+        <principal-database>
+            <!-- A name for referencing this database-->
+            <name>passwordfile</name>
+            <!-- The type of principal database -->
+            <class>org.apache.qpid.server.security.auth.database.PlainPasswordFilePrincipalDatabase</class>
+            <!-- Any attributes associated with the database. Here it is a password file to load. -->
+            <attributes>
+                <attribute>
+                    <name>passwordFile</name>
+                    <value>${conf}/passwd</value>
+                </attribute>
+            </attributes>
+        </principal-database>
+    </principal-databases>
+    <!-- This access value can be any access manager. The built in defaults are AllowAll and DenyAll -->
+    <access>
+        <class>org.apache.qpid.server.security.access.plugin.AllowAll</class>    <!-- NOTE class change in M2.1 -->
+    </access>
+    <!-- Properties required when running the JMX Management console. -->
+    <jmx>
+       <!-- Access file that allows users rights to access the management console. -->
+       <access>${conf}/jmxremote.access</access>
+       <!-- The principal database to use to authenticate users. -->
+       <principal-database>passwordfile</principal-database>
+    </jmx>        
+</security>
+
+
+ +

Virtualhosts

+ +

This section allows you to define the set of virtual hosts which will be contained in your broker instance, and the message store & location for each. NB: The commented out section referencing BDBMessageStore should be used for all applications wishing to use persistence to disk.

+ +

If you are using transient messaging you can use the MemoryMessageStore, with the caveat that scalability for transient use is limited by heap size.

+ +

In our example config.xml, we define three virtual hosts which we commonly use for development (development), system testing (test) and integration testing (localhost). In the config.xml the per virtual host sections define both the Message Store in use (MemoryMessageStore for non-persistent applications or BDBMessageStore for persistent application usage) and the security for each virtual host. The security settings are under currently development so subject to changes.

+ +

The default virtual host for connections which do not specify a host on the url is 'test' in the example config.xml.

+ +
+
<virtualhost>
+            <name>localhost</name>
+            <localhost>
+                <store>
+                    <!-- <class>org.apache.qpid.server.store.berkeleydb.BDBMessageStore</class>
+                    <environment-path>${work}/localhost-store</environment-path> -->
+
+                    <class>org.apache.qpid.server.store.MemoryMessageStore</class>
+                </store>                
+            </localhost>
+        </virtualhost>
+
+
+ +

Heartbeat

+ +

The Qpid broker sends an internal (only) heartbeat. This element allows configuration of the frequency of this heartbeat. At present, we recommend that you leave this section unchanged !

+ +
+
<heartbeat>
+    <delay>0</delay>
+    <timeoutFactor>2.0</timeoutFactor>
+</heartbeat>
+
+
+ +

Queue

+ +

This should NOT be changed lightly as it sets the broker up to automatically bind queues to exchanges.

+ +

It could theoretically be used to prevent users creating new queues at runtime, assuming that you have created all queues/topics etc at broker startup. However, best advice is to leave unchanged for now.

+ +
+
<queue>
+    <auto_register>true</auto_register>
+</queue>
+
+
+ +

Virtualhosts

+ +

This element allows you to specify a location for the virtualhosts.xml file that you wish to use. If you are not using a subdirectory under $QPID_HOME you can provide a fully qualified path instead. For more information on the content of the virtualhosts.xml file please see Configure the Virtual Hosts via virtualhosts.xml

+ +
+
<virtualhosts>${conf}/virtualhosts.xml</virtualhosts>
+
+
+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Mailing Lists.html b/documentation/content/xdocs/Mailing Lists.html new file mode 100755 index 0000000000..823d49fc12 --- /dev/null +++ b/documentation/content/xdocs/Mailing Lists.html @@ -0,0 +1,67 @@ + + + Apache Qpid : Mailing Lists + + + + + + + + + +
+
+ + Apache Qpid : Mailing Lists + +
+
+ This page last changed on Apr 11, 2008 by cctrieloff. +
+ +

Qpid User List

+ +

The user's list is for discussions that relate to use or questions on Qpid. If you have questions about how a feature works, suggestions on additional requirements, or general questions about Qpid please use this list

+ + + + +

Qpid Developer List

+ +

The developer's list is for discussions that relate to the on going development of Qpid. If you have questions about how a feature is being developed, suggestions on how to implement a new feature, or requests for a new feature this is the list to use.

+ + + + +

Qpid Commits List

+ +

The commits list is for recieving notifications about code being committed to the Qpid repository. The trafic on this list is automatically generated by Subversion. You should not post messages to this list.

+ + + + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Management Design notes.html b/documentation/content/xdocs/Management Design notes.html new file mode 100755 index 0000000000..f16fa90f99 --- /dev/null +++ b/documentation/content/xdocs/Management Design notes.html @@ -0,0 +1,714 @@ + + + Apache Qpid : Management Design notes + + + + + + + + + +
+
+ + Apache Qpid : Management Design notes + +
+
+ This page last changed on Feb 06, 2008 by cctrieloff. +
+ +

Management design notes:

+ +
    +
  • The schema is checked into svn.
    • +
+ + + +

Todo / info to fill out:

+ +
    +
  • Gateway defintions for SNMP, JMX etc..
    • +
+ + + +

Management Requirements

+ +
    +
  • Must operate from a formally defined management schema.
    • +
  • Must natively use the AMQP protocol and its type system.
    • +
  • Must support the following operations +
      +
    • SET operation on configurable (persistent) aspects of objects
      • +
    • GET operation on all aspects of objects
      • +
    • METHOD invocation on schema-defined object-specific methods
      • +
    • Distribution of unsolicited periodic updates of instrumentation data +
        +
      • Data updates shall carry an accurate sample timestamp for rate calculation
        • +
      • Updates shall carry object create/delete timestamps.
        • +
      • Transient objects shall be fully accounted for via updates. Note that short-lived transient objects may come and go within a single update interval. All of the information pertaining to such an object must be captured and transmitted.
        • +
      +
      • +
    • Distribution of unsolicited event and/or alert indications (schema defined)
      • +
    +
    • +
  • Role-based access control at object, operation, and method granularity
    • +
  • End-to-end encryption and signing of management content
    • +
  • Schema must be self-describing so the management client need not have prior knowledge of the management model of the system under management.
    • +
  • Must be extensible to support the management of objects beyond the AMQP component set. This allows AMQP to be used as a general-purpose management protocol.
    • +
+ + +

Architectural Framework

+ +

There are two primary interfaces defined in the management architecture:

+
    +
  1. The Management Console Interface is used by management clients (CLIs, GUIs, console servers, etc.) to remotely access management data.
    2. +
  2. The Extension Interface is used by software components (not necessarily related to the AMQP infrastructure) to provide access to their managed objects.
    3. +
+ + +
+
        +---------+    +---------+        +---------+
+        |         |    |         |        |         |
+        | CLI/GUI |    | Console |<======>| CLI/GUI |
+        |         |    | Server  |        |         |
+        +---------+    |         |        +---------+
+             ^         +---------+
+             |              ^
+             |              |
+             v              v
+        +---------------------------------+
+        |                                 |
+        |   Managed AMQP Infrastructure   |
+        |                                 |
+        +---------------------------------+
+                      ^
+                      |
+                      v
+                +------------+
+                |            |-+
+                | Management | |-+
+                | Extensions | | |
+                |            | | |
+                +------------+ | |
+                  +------------+ |
+                    +------------+
+
+
+ +

Both management interfaces are based on the AMQP protocol and its type system.

+ +

Definitions of Terms

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
class A type definition for a manageable object.
package A grouping of class definitions that are related to a single software component. The package concept is used to extend the management schema beyond just the AMQP software components.
object Also "manageable object". An instantiation of a class. An object represents a physical or logical component in the core function of the system under management.
configuration element A typed member of a class which represents a configurable attribute of the class. Configurable attributes are persistent on the system under management (i.e. they are inherent to the system or are stored in a configuration file on the system).
instrumentation element A typed member of a class which represents an instrumentation attribute of the class. Instrumentation elements are typically counters or state values.
method A member of a class which represents a callable procedure on an object of the class. Methods may have an arbitrary set of typed arguments and may supply a return code. Methods typically have side effects on the associated object.
event A member of a class which represents the occurence of an event of interest within the system under management.
management agent A software component built into the broker that handles management traffic and distributes management data.
+ +

The Management Exchange

+ +

The management exchange (called "qpid.management" currently) is a special type of exchange used for remote management access to the Qpid broker. The management exchange is an extension of the standard "Topic" exchange. It behaves like a topic exchange with the following exceptions:

+
    +
  1. When a queue is successfully bound to the exchange, a method is invoked on the broker's management agent to notify it of the presence of a new remote managment client.
    2. +
  2. When messages arrive at the exchange for routing, the exchange examines the message's routing key and if the key represents a management command or method, it routes it directly to the management agent rather than routing it to queues using the topic algorithm.
    +The management exchange is used by the management agent to distribute unsolicited management data. Such data is classified by the routing key allowing management clients to register for only the data they need.
    3. +
+ + +

Management Message Protocol

+ +

The principals in a management exchange are the management client and the management agent. The management agent is integrated into the AMQP broker and the management client is a remote entity. A management agent may be managed by zero or more management clients at any given time. Additionally, a management client may manage multiple management agents at the same time.

+ +

For authentication and access control, management relies on the mechanisms supplied by the AMQP protocol.

+ +

Establishing Communication Between Client and Agent

+ +

Communication is established between the management client and management agent using normal AMQP procedures. The client creates a connection to the broker and then establishes a session with its corresponding channel.

+ +

Two private queues are then declared (only one if method invocation is not needed). A management queue is declared and bound to the qpid.management exchange. If the binding key is "mgmt.#", all management-related messages sent to the exchange will be received by this client. A more specific binding key will result in a more restricted set of messages being received (see the section on Routing Key Structure below).

+ +

If methods are going to be invoked on managed objects, a second private queue must be declared so the client can receive method replies. This queue is bound to the amq.direct exchange using a routing key equal to the name of the queue.

+ +

When a client successfully binds to the qpid.management exchange, the management agent schedules a schema broadcast to be sent to the exchange. The agent will publish, via the exchange, a description of the schema for all manageable objects in its control.

+ +
+
      Client                                                          Agent
+        |                                                               |
+        | --- AMQP Connection and Session Setup ----------------------> |
+        |                                                               |
+        | --- Queue.declare (private data queue) ---------------------> |
+        | --- Bind queue to exchange 'qpid.management' key 'mgmt.#' --> |
+        |                                                               |
+        | --- Queue.declare (private method-reply queue) -------------> |
+        | --- Bind queue to exchange 'amq.direct' --------------------> |
+        |                                                               |
+        | <------- Management schema via exchange 'qpid.management' --- |
+        |                                                               |
+
+
+ +

Broadcast of Configuration and Instrumentation Updates

+ +

The management agent will periodically publish updates to the configuration and instrumentation of management objects under its control. Under normal circumstances, these updates are published only if they have changed since the last time they were published. Configuration updates are only published if configuration has changed and instrumentation updates are only published if instrumentation has changed. The exception to this rule is that after a management client binds to the qpid.management exchange, all configuration and instrumentation records are published as though they had changed whether or not they actually did.

+ +
+
      Client                                                          Agent
+        |                                                               |
+        | <-------------- Object Configurations via 'mgmt.config.#' --- | |
+        | <--------------- Object Instrumentation via 'mgmt.inst.#' --- | |
+        |                                                               | |
+        |                                                               | | Publish Interval
+        |                                                               | |
+        |                                                               | |
+        |                                                               | V
+        | <-------------- Object Configurations via 'mgmt.config.#' --- |
+        | <--------------- Object Instrumentation via 'mgmt.inst.#' --- |
+        |                                                               |
+
+
+ +

Invoking a Method on a Managed Object

+ +

When the management client wishes to invoke a method on a managed object, it sends a method request message to the qpid.management exchange. The routing key contains the object class and method name (refer to Routing Key Structure below). The method request must have a header entry (reply-to) that contains the name of the method-reply queue so that the method response can be properly routed back to the requestor.

+ +

The method request contains a sequence number that is copied to the method reply. This number is opaque to the management agent and may be used by the management client to correlate the reply to the request. The asynchronous nature of requests and replies allows any number of methods to be in-flight at a time. Note that there is no guarantee that methods will be replied to in the order in which they were requested.

+ +
+
      Client                                                          Agent
+        |                                                               |
+        | --- Method Request (to exchange 'qpid.management') ---------> |
+        |                                                               |
+        |                                                               |
+        | <--------------- Method Reply (via exchange 'amq.direct') --- |
+        |                                                               |
+
+
+ +

Routing Key Structure

+ +

As noted above, the structure of the binding and routing keys used on the management exchange is important to the function of the management architecture. The routing key of a management message determines:

+
    +
  1. The type of message (i.e. operation request or unsolicited update).
    2. +
  2. The class of the object that the message pertains to.
    3. +
  3. The specific operation or update type.
    4. +
  4. The namespace in which the class belongs. This allows for plug-in expansion of the management schema for manageable objects that are outside of the broker itself.
    5. +
+ + +

Placing this information in the routing key provides the ability to enforce access control at class, operation, and method granularity. It also separates the command structure from the content of the management message (i.e. element values) allowing the content to be encrypted and signed end-to-end while still allowing access control at the message-transport level. This means that special access control code need not be written for the management agent.
+There are two general types of routing/binding key:

+
    +
  • Command keys have the structure: method.<package>.<class>.<method> where +
      +
    • <package> is the namespace in which the <class> name is valid,
      • +
    • <class> is the name of the class as defined in the schema, and
      • +
    • <method> is one of "get", "set", or a schema-defined class-specific method name.
      • +
    +
    • +
  • Unsolicited keys have the structure: mgmt.<type>.<package>.<class>.<severity> where +
      +
    • <type> is one of "schema", "config", "inst", or "event",
      • +
    • <package> is the namespace in which the <class> name is valid, and
      • +
    • <class> is the name of the class as defined in the schema.
      • +
    • <severity> is relevant for events only. It is one of "critical", "error", "warning", or "info".
      • +
    +
    • +
+ + +

In both cases, the content of the message (i.e. method arguments, element values, etc.) is carried in the body segment of the message.

+ +

The <package> namespace allows this management framework to be extended with the addition of other software packages.

+ +

Management Message Body Structure

+ +

The body segments of management messages are composed of sequences of binary-encoded data fields, in a manner consistent with the 0-10 version of the AMQP specification.

+ +

All management messages begin with a message header:

+ +
+
          octet 0      1         2         3         4         5
+        +---------+---------+---------+---------+---------+---------+
+        |   'A'   |   'M'   |   '0'   |   '1'   | opcode  |  class  |
+        +---------+---------+---------+---------+---------+---------+
+
+
+ +

The first four octets contain the protocol magic number "AM01" which is used to identify the type and version of the message.

+ +

The opcode field identifies the operation represented by the message:

+ + + + + + + + + + + + + + + + + + + + + + +
opcodedescription
'S'This message contains a schema record which describes the full schema description for a single object class
'C'This message contains a content record. Content records contain the values of all configuration or instrumentation elements in an object. Such records are broadcast on a periodic interval if 1) a change has been made in the value of one of the elements, or 2) if a new management client has bound a queue to the management exchange.
'M'This message contains a method request
'R'This message contains a method reply
+ +

The class field identifies the type of content data in a content record. If the opcode is not 'C', this field must be set to zero.

+ + + + + + + + + + + + + + +
classdescription
'C'Configuration content
'I'Instrumentation content
+ +

Schema Messages

+ +

Schema messages are published periodically if 1) the first instance of the object class has been created, or 2) a new management client has bound a queue to the management exchange. A schema message contains all schema-related data for a single object class.

+ +
+
        +-----+-----+-----+-----+-----+-----+
+        | 'A' | 'M' | '0' | '1' | 'S' |  0  |
+        +-----+-----+-----+-----+-----+-----+----------------------+
+        |                packageName (short string)                |
+        +----------------------------------------------------------+
+        |                className (short string)                  |
+        +----------------------------------------------------------+
+        |                schema-hash (bin128)                      |
+        +-----------+-----------+-----------+-----------+----------+
+        | configCnt |  instCnt  | methodCnt | eventCnt  |
+        +-----------+-----------+-----------+-----------+----------------------------+
+        | configCnt config-element records                                           |
+        +----------------------------------------------------------------------------+
+        | instCnt   instrumentation-element records                                  |
+        +----------------------------------------------------------------------------+
+        | methodCnt method records                                                   |
+        +----------------------------------------------------------------------------+
+        | eventCnt  event records                                                    |
+        +----------------------------------------------------------------------------+
+
+
+ +

Each config-element record is an AMQP field table with the following fields. Optional fields may optionally be omitted from the field table.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
field nameoptionaldescription
namenoName of the configuration element
typenoType code for the element
accessnoAccess code for the element
indexno1 = index element, 0 = not an index element
unityesUnits for numeric values (i.e. seconds, bytes, etc.)
minyesMinimum value for numerics
maxyesMaximum value for numerics
maxlenyesMaximum length for strings
descyesDescription of the element
+ +

Each instrumentation-element record is an AMQP field table with the following fields:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
field nameoptionaldescription
namenoName of the instrumentation element
typenoType code for the element
unityesUnits for numeric values (i.e. seconds, bytes, etc.)
descyesDescription of the element
+ +

method and event records contain a main field table that describes the method or header followed by zero or more field tables describing arguments. The main field table contains the following fields:

+ + + + + + + + + + + + + + + + + + + + + + +
field nameoptionaldescription
namenoName of the method or event
argCountnoNumber of argument records to follow
descyesDescription of the method or event
+ +

Argument field tables contain the following fields:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
field namemethodeventoptionaldescription
nameyesyesnoArgument name
typeyesyesnoType code for the argument
diryesnoyesDirection code for method arguments
unityesyesyesUnits for numeric values (i.e. seconds, bytes, etc.)
minyesnoyesMinimum value for numerics
maxyesnoyesMaximum value for numerics
maxlenyesnoyesMaximum length for strings
descyesyesyesDescription of the argument
defaultyesnoyesDefault value for the argument
+ +

type codes are numerics with the following values:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
valuetype
1uint8
2uint16
3uint32
4uint64
6short string
7long string
+ +

access codes are numerics with the following values:

+ + + + + + + + + + + + + + + + + + +
valueaccess
1Read-Create access
2Read-Write access
3Read-Only access
+ +

direction codes are numerics with the following values:

+ + + + + + + + + + + + + + + + + + +
valuedirection
1Input (from client to broker)
2Output (from broker to client)
3IO (bidirectional)
+ +

Configuration and Instrumentation Content Messages

+ +

Content messages are published when changes are made to the values of content or instrumentation elements or when new management clients bind a queue to the management exchange.

+ +
+
        +-----+-----+-----+-----+-----+-----+
+        | 'A' | 'M' | '0' | '1' | 'C' | cls |
+        +-----+-----+-----+-----+-----+-----+----------------------+
+        |                packageName (short string)                |
+        +----------------------------------------------------------+
+        |                className (short string)                  |
+        +----------------------------------------------------------+
+        |                class hash (bin128)                       |
+        +-----+-----+-----+-----+-----+-----+-----+-----+----------+
+        | timestamp of current sample (datetime)        |
+        +-----+-----+-----+-----+-----+-----+-----+-----+
+        | time object was created (datetime)            |
+        +-----+-----+-----+-----+-----+-----+-----+-----+
+        | time object was deleted (datetime)            |
+        +-----+-----+-----+-----+-----+-----+-----+-----+
+        | objectId (uint64)                             |
+        +-----+-----+-----+-----+-----+-----+-----+-----+------------------------+
+        | config/inst values (in schema order)                                   |
+        +------------------------------------------------------------------------+
+
+
+ +

All timestamps are uint64 values representing nanoseconds since the epoch (January 1, 1970). The objectId is a uint64 value that uniquely identifies this object instance.

+ +

The element values are encoded by their type into the message in the order in which they appeared in the schema message.

+ +

Method Request and Reply Messages

+ +

Method request messages have the following structure. The sequence number is opaque to the management agent. It is returned unchanged in the method reply so the calling client can correctly associate the reply to the request. The objectId is the unique ID of the object on which the method is to be executed.

+ +
+
        +-----+-----+-----+-----+-----+-----+
+        | 'A' | 'M' | '0' | '1' | 'M' |  0  |
+        +-----+-----+-----+-----+-----+-----+
+        |  sequence number      |
+        +-----------------------+-----------------------+
+        |  objectId                                     |
+        +-----------------------------------------------+------------------------+
+        |  input and bidirectional argument values (in schema order)             |
+        +------------------------------------------------------------------------+
+
+
+ +

Method reply messages have the following structure. The sequence number is identical to that supplied in the method request. The status code (and text) indicate whether or not the method was successful and if not, what the error was. Output and bidirectional arguments are only included if the status code was 0 (STATUS_OK).

+ +
+
        +-----+-----+-----+-----+-----+-----+
+        | 'A' | 'M' | '0' | '1' | 'R' |  0  |
+        +-----+-----+-----+-----+-----+-----+
+        |  sequence number      |
+        +-----------------------+
+        |  status code          |
+        +-----------------------+----------------------------------+
+        |  status text (short string)                              |
+        +-----------------------+----------------------------------+-------------+
+        |  output and bidirectional argument values (in schema order)            |
+        +------------------------------------------------------------------------+
+
+
+ +

status code values are:

+ + + + + + + + + + + + + + + + + + + + + + +
valuedescription
0 STATUS_OK - successful completion
1 STATUS_UNKNOWN_OBJECT - objectId not found in the agent
2 STATUS_UNKNOWN_METHOD - method is not known by the object type
3 STATUS_NOT_IMPLEMENTED - method is not currently implemented
+ +
+
+ Attachments: +
+ +
+ + QpidMgmtSchema.xml (text/xml) +
+
+ +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Management Design notes_attachments/QpidMgmtSchema.xml b/documentation/content/xdocs/Management Design notes_attachments/QpidMgmtSchema.xml new file mode 100755 index 0000000000..3158a5fd71 --- /dev/null +++ b/documentation/content/xdocs/Management Design notes_attachments/QpidMgmtSchema.xml @@ -0,0 +1,268 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/documentation/content/xdocs/Management Tools.html b/documentation/content/xdocs/Management Tools.html new file mode 100755 index 0000000000..7cf41fd335 --- /dev/null +++ b/documentation/content/xdocs/Management Tools.html @@ -0,0 +1,45 @@ + + + Apache Qpid : Management Tools + + + + + + + + + +
+
+ + Apache Qpid : Management Tools + +
+
+ This page last changed on Jul 04, 2007 by ritchiem. +
+ +

Current Management Tools

+ +

This is a list of the current managment tools available for the Qpid Java Broker.

+ + + + + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/MartinRitchie.html b/documentation/content/xdocs/MartinRitchie.html new file mode 100755 index 0000000000..2586c3b3bd --- /dev/null +++ b/documentation/content/xdocs/MartinRitchie.html @@ -0,0 +1,36 @@ + + + Apache Qpid : MartinRitchie + + + + + + + + + +
+
+ + Apache Qpid : MartinRitchie + +
+
+ This page last changed on Apr 14, 2008 by ritchiem. +
+ +

This is just a sandbox test area for Martin Ritchie

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/MemoryMessageStore.html b/documentation/content/xdocs/MemoryMessageStore.html new file mode 100755 index 0000000000..39a7693291 --- /dev/null +++ b/documentation/content/xdocs/MemoryMessageStore.html @@ -0,0 +1,38 @@ + + + Apache Qpid : MemoryMessageStore + + + + + + + + + +
+
+ + Apache Qpid : MemoryMessageStore + +
+
+ This page last changed on Jul 04, 2007 by ritchiem. +
+ +

MemoryMessageStore

+ +

This is the default MemoryStore it performs no persistence between broker restarts.

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Message API Design.html b/documentation/content/xdocs/Message API Design.html new file mode 100755 index 0000000000..5eaa5c6a13 --- /dev/null +++ b/documentation/content/xdocs/Message API Design.html @@ -0,0 +1,182 @@ + + + Apache Qpid : Message API Design + + + + + + + + + +
+
+ + Apache Qpid : Message API Design + +
+
+ This page last changed on Aug 15, 2007 by rajith. +
+ +

Message API Design

+ +

This document describes the new message API for the restructured client.

+ +
    +
  • Sending Messages
    • +
  • Receiving Messages
    • +
  • Message abstraction
    • +
  • Java Doc
    • +
+ + +

Sending Messages

+

The Session class provides the following methods to send messages.

+ +
+
public interface Session{
+.........
+
+//Option1 - for small messages
+public void messageTransfer(String destination, Message msg, short confirmMode, short acquireMode)throws IOException;
+
+//Option2 - for large messages
+public void messageStream(String destination, Message msg, short confirmMode, short acquireMode)throws IOException;
+ 
+//Option3 - can use it with any message size, recomended for large messages
+public void messageTransfer(String destination, short confirmMode, short acquireMode);
+public void headers(Struct... headers);
+public void data(byte[] data);
+public void data(ByteBuffer buf);
+public void data(String str);
+public void endData();
+
+.........
+
+}
+
+ +

Sending small Messages

+

Option1 provides a convinience method to send small messages.
+You could use the ByteBufferMessage to create small in memory messages (or your own implementation).
+Underneath it maps onto methods defined under option3

+ +

Sending large Messages

+

You have two options for sending large messages, using either pull style or push style semantics

+ +

Using the Session class methods (Option3)

+

Option3 provides a more natural AMQP style set of methods
+You can stream data using Option3 by pushing your data using one of the data methods defined in the session class.

+ +

Using Option2 (pull style)

+

The messageStream method will pull data from the message and stream using the methods defined in option3.
+You could use FileMessage or StreamingMessage or your own Message implementation that backs a large data stream.

+ +
    +
  • FileMessage takes in a FileInputStream and create a nio FileChannel. It then uses a MappedByteBuffer to map a region of the file when the readData method is invoked. You could specify a chunksize in the constructor to control how much data is mapped each time.
    • +
+ + +
    +
  • StreamingMessage takes in a SocketChannel and reads a chunk of data at a time until the SocketChannel is closed. This could be useful when u need to transfer a data stream received from a legacy application or a hardware device. In such cases the StreamingMessage provides a convinient abstraction to stream the data without any intermediate copying.
    • +
+ + +

Receiving Messages

+

To receive messages you can subscribe using the following method

+
+
public interface Session{
+.........
+
+public void messageSubscribe(String queue, String destination, short confirmMode, short acquireMode,
+                                 MessagePartListener listener, Map<String, ?> filter, Option... options);
+-----
+}
+
+ +

The API provides support for receiving messages in parts as and when they arrive using the MessagePartListener.
+This enables the user to start consuming the message while it is being streamed.

+
+
public interface MessagePartListener{
+
+public void messageTransfer(long transferId);
+
+public void messageHeaders(Struct... headers);
+
+public void data(ByteBuffer src);
+
+public void messageReceived();
+
+}
+
+ +

The messageTransfer method signals the start of a transfer and passes the transferId.
+The Transfer Id is used for the following operations defined in the Session API.

+
    +
  • to Acquire the message (if the message was transfered in no-acquire mode)
    • +
  • to release the message ( if already acquired)
    • +
  • to Reject or Acknowledge the message
    • +
+ + +

The data method will be called each time Frame arrives. The messageReceived method will signal the end of the message.

+ +

Consuming small messages

+

The API also provides a convinient way for consuming small messages through the MessageListener interface and the MessagePartListenerAdapter.
+The MessagePartListenerAdapter will build the message and will notify the user through MessageListener when the message is complete.

+
+
public interface MessageListener{
+ 
+ public void onMessage(Message message);  
+
+}
+
+ +

you can use it the following way.

+
+
.........
+
+ MessageListener myMessageListener .... 
+
+ session.messageSubscribe(....,new MessagePartListenerDapter(myMessageListener),...);
+-----
+
+ + +

Message abstraction

+

Message Interface provides an abstraction for creating messages from different data streams.
+Please read the java doc for a complete description of each method.

+ +
+
public interface Message{
+
+public MessageProperties getMessageProperties();
+public DeliveryProperties getDeliveryProperties();
+
+public void appendData(byte[] src) throws IOException;
+public void appendData(ByteBuffer src) throws IOException;
+
+public void readData(byte[] target) throws IOException;   
+public ByteBuffer readData() throws IOException;
+
+public void clearData();
+public long getMessageTransferId();
+
+}
+
+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/MessageStore Tool.html b/documentation/content/xdocs/MessageStore Tool.html new file mode 100755 index 0000000000..39578c735a --- /dev/null +++ b/documentation/content/xdocs/MessageStore Tool.html @@ -0,0 +1,115 @@ + + + Apache Qpid : MessageStore Tool + + + + + + + + + +
+
+ + Apache Qpid : MessageStore Tool + +
+
+ This page last changed on Jul 05, 2007 by ritchiem. +
+ +

h2 MessageStore Tool

+ +

We have a number of implementations of MessageStore this tool allows the interrogation of these stores while the broker is offline.

+ +

MessageStore Implementations

+ + + +

Introduction

+

Each of the MessageStore implementations provide different back end storage for their messages and so would need a different tool to be able to interrogate their contents. What this tool does is to utilise the Java broker code base to access the contents of the storage providing the user with a consistent means to inspect the storage contents. The tool allows the current messages in the store to be inspected and copied/moved between queues.

+ + +

Usage

+ +

The tools-distribution currently includes a unix shell command 'msTool.sh' this script will launch the java tool.

+ +

The tool loads $QPID_HOME/etc/config.xml by default. If an alternative broker configuration is required this should be provided on the command line as would be done for the broker.

+ +
+
msTool.sh -c <path to different config.xml>
+
+
+ +

On startup the user is present with a command prompt

+ +
+
$ msTool.sh
+MessageStoreTool - for examining Persistent Qpid Broker MessageStore instances
+bdb$ 
+
+
+ +

Available Commands

+ +

The available commands in the tool can be seen through the use of the 'help' command.

+ +
+
bdb$ help
++----------------------------------------------------------------+
+|                       Available Commands                       |
++----------------------------------------------------------------+
+| Command | Description                                          |
++----------------------------------------------------------------+
+| quit    | Quit the tool.                                       |
+| list    | list available items.                                |
+| dump    | Dump selected message content. Default: show=content |
+| load    | Loads specified broker configuration file.           |
+| clear   | Clears any selection.                                |
+| show    | Shows the messages headers.                          |
+| select  | Perform a selection.                                 |
+| help    | Provides detailed help on commands.                  |
++----------------------------------------------------------------+
+bdb$
+
+
+ + +

A brief description is displayed and further usage information is shown with 'help <command>'

+ +
+
bdb$ help list
+list availble items.
+Usage:list queues [<exchange>] | exchanges | bindings [<exchange>] | all
+bdb$
+
+
+ + +

Future Work

+ +

Currently the tool only works whilst the broker is offline. If this functionality was incorporated into the broker then a telnet functionality could be provided allowing online management.

+ + + + + + + + + + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/MgmtC++.html b/documentation/content/xdocs/MgmtC++.html new file mode 100755 index 0000000000..9aae04d028 --- /dev/null +++ b/documentation/content/xdocs/MgmtC++.html @@ -0,0 +1,333 @@ + + + Apache Qpid : MgmtC++ + + + + + + + + + +
+
+ + Apache Qpid : MgmtC++ + +
+
+ This page last changed on Apr 15, 2008 by cctrieloff. +
+ +

Managing the C++ Broker

+ +

There are quite a few ways to interact with the C++ broker. The command line tools
+include:

+
    +
  • qpid-route - used to configure federation (a set of federated brokers)
    • +
  • qpid-config - used to configure queues, exchanges, bindings and list them etc
    • +
  • qpid-tool - used to view management information/statistics and call any management actions on the broker
    • +
+ + +

Using qpid-config

+ +

This utility can be used to create queues exchanges and bindings, both durable and transient. Always check for latest options by running --help command.

+
+
$ ./qpid-config --help
+Usage:  qpid-config OPTIONS
+        qpid-config OPTIONS exchanges filter-string
+        qpid-config OPTIONS queues    filter-string
+        qpid-config OPTIONS add exchange <type> <name> AddExchangeOptions
+        qpid-config OPTIONS del exchange <name>
+        qpid-config OPTIONS add queue <name> AddQueueOptions
+        qpid-config OPTIONS del queue <name>
+        qpid-config OPTIONS bind   <exchange-name> <queue-name> binding-key
+        qpid-config OPTIONS unbind <exchange-name> <queue-name> binding-key
+Options:
+    -b [ --bindings ]                         Show bindings in queue or exchange list
+    -a [ --broker-addr ] Address (localhost)  Address of qpidd broker
+         broker-addr is in the form:   hostname | ip-address :<port>
+         ex:  localhost, 10.1.1.7:10000, broker-host:10000
+    -s [ --spec-file] Path (/usr/share/amqp/amqp.0-10-preview.xml)
+                                              AMQP specification file
+Add Queue Options:
+    --durable           Queue is durable
+
+Add Exchange Options:
+    --durable           Exchange is durable
+
+

Get the summary page

+
+
./qpid-config
+Total Exchanges: 6
+          topic: 2
+        headers: 1
+         fanout: 1
+         direct: 2
+   Total Queues: 7
+        durable: 0
+    non-durable: 7
+
+

List the queues

+
+
$ ./qpid-config  queues
+                                      Store Size
+Durable  AutoDel  Excl  Bindings  (files x file pages)  Queue Name
+===========================================================================================
+   N        N      N         1                          pub_start
+   N        N      N         1                          pub_done
+   N        N      N         1                          sub_ready
+   N        N      N         1                          sub_done
+   N        N      N         1                          perftest0
+   N        Y      N         2                          mgmt-3206ff16-fb29-4a30-82ea-e76f50dd7d15
+   N        Y      N         2                          repl-3206ff16-fb29-4a30-82ea-e76f50dd7d15
+   N        Y      N         2                          mgmt-df06c7a6-4ce7-426a-9f66-da91a2a6a837
+   N        Y      N         2                          repl-df06c7a6-4ce7-426a-9f66-da91a2a6a837
+
+

List the exchanges with bindings

+
+
$ ./qpid-config -b exchanges
+Exchange '' (direct)
+    bind pub_start => pub_start
+    bind pub_done => pub_done
+    bind sub_ready => sub_ready
+    bind sub_done => sub_done
+    bind perftest0 => perftest0
+    bind mgmt-3206ff16-fb29-4a30-82ea-e76f50dd7d15 => mgmt-3206ff16-fb29-4a30-82ea-e76f50dd7d15
+    bind repl-3206ff16-fb29-4a30-82ea-e76f50dd7d15 => repl-3206ff16-fb29-4a30-82ea-e76f50dd7d15
+Exchange 'amq.direct' (direct)
+    bind repl-3206ff16-fb29-4a30-82ea-e76f50dd7d15 => repl-3206ff16-fb29-4a30-82ea-e76f50dd7d15
+    bind repl-df06c7a6-4ce7-426a-9f66-da91a2a6a837 => repl-df06c7a6-4ce7-426a-9f66-da91a2a6a837
+    bind repl-c55915c2-2fda-43ee-9410-b1c1cbb3e4ae => repl-c55915c2-2fda-43ee-9410-b1c1cbb3e4ae
+Exchange 'amq.topic' (topic)
+Exchange 'amq.fanout' (fanout)
+Exchange 'amq.match' (headers)
+Exchange 'qpid.management' (topic)
+    bind mgmt.# => mgmt-3206ff16-fb29-4a30-82ea-e76f50dd7d15
+
+ +

Using qpid-route

+ +

This utility is to create federated networks of brokers, This allows you for forward messages between brokers in a network. Think of it like an IP network and static routes are configured with direct exchanges, and dynamic routes configured with the topic exchanges. The '*' and '#' can be used to create IP masking type pattern as you would with IP address except you are using the topic names.

+ +

The utility thus looks much like iproute

+
+
$ ./qpid-route --help
+Usage:  qpid-route OPTIONS add   <dest-broker> <src-broker> <exchange> <routing-key>
+        qpid-route OPTIONS del   <dest-broker> <src-broker> <exchange> <routing-key>
+        qpid-route OPTIONS list  <dest-broker>
+        qpid-route OPTIONS flush <dest-broker>
+Options:
+    -s [ --spec-file ] PATH (/usr/share/amqp/amqp.0-10.xml)
+    -v [ --verbose ]              Verbose output
+    -q [ --quiet ]                Quiet output, don't print duplicate warnings
+  dest-broker and src-broker are in the form:   hostname | ip-address :<port>
+  ex:  localhost, 10.1.1.7:10000, broker-host:10000
+
+

A few examples:

+
+
./qpidd_route -v add host1 host2 hub1.topic hub2.topic.stock.buy
+./qpidd_route -v add host1 host2 hub1.topic hub2.topic.stock.sell
+./qpidd_route -v add host1 host2 hub1.topic 'hub2.topic.stock.#'
+./qpidd_route -v add host1 host2 hub1.topic 'hub2.#'
+./qpidd_route -v add host1 host2 hub1.topic 'hub2.topic.#'
+./qpidd_route -v add host1 host2 hub1.topic 'hub2.global.#'
+
+ +

Using qpid-tool

+ +

This utility provided a telnet style interface to be able to view, list all stats and action
+all the methods. Simple capture below. Best to just play with it and mail the list if you have
+questions or want features added.

+ +
+
qpid:
+qpid: help
+Management Tool for QPID
+Commands:
+    list                            - Print summary of existing objects by class
+    list <className>                - Print list of objects of the specified class
+    list <className> all            - Print contents of all objects of specified class
+    list <className> active         - Print contents of all non-deleted objects of specified class
+    list <list-of-IDs>              - Print contents of one or more objects (infer className)
+    list <className> <list-of-IDs>  - Print contents of one or more objects
+        list is space-separated, ranges may be specified (i.e. 1004-1010)
+    call <ID> <methodName> <args> - Invoke a method on an object
+    schema                          - Print summary of object classes seen on the target
+    schema <className>              - Print details of an object class
+    set time-format short           - Select short timestamp format (default)
+    set time-format long            - Select long timestamp format
+    quit or ^D                      - Exit the program
+qpid: list
+Management Object Types:
+    ObjectType     Active  Deleted
+    ================================
+    qpid.binding   21      0
+    qpid.broker    1       0
+    qpid.client    1       0
+    qpid.exchange  6       0
+    qpid.queue     13      0
+    qpid.session   4       0
+    qpid.system    1       0
+    qpid.vhost     1       0
+qpid: list qpid.system
+Objects of type qpid.system
+    ID    Created   Destroyed  Index
+    ==================================
+    1000  21:00:02  -          host
+qpid: list 1000
+Object of type qpid.system: (last sample time: 21:26:02)
+    Type    Element   1000
+    =======================================================
+    config  sysId     host
+    config  osName    Linux
+    config  nodeName  localhost.localdomain
+    config  release   2.6.24.4-64.fc8
+    config  version   #1 SMP Sat Mar 29 09:15:49 EDT 2008
+    config  machine   x86_64
+qpid: schema queue
+Schema for class 'qpid.queue':
+    Element                Type          Unit         Access      Notes   Description
+    ===================================================================================================================
+    vhostRef               reference                  ReadCreate  index
+    name                   short-string               ReadCreate  index
+    durable                boolean                    ReadCreate
+    autoDelete             boolean                    ReadCreate
+    exclusive              boolean                    ReadCreate
+    arguments              field-table                ReadOnly            Arguments supplied in queue.declare
+    storeRef               reference                  ReadOnly            Reference to persistent queue (if durable)
+    msgTotalEnqueues       uint64        message                          Total messages enqueued
+    msgTotalDequeues       uint64        message                          Total messages dequeued
+    msgTxnEnqueues         uint64        message                          Transactional messages enqueued
+    msgTxnDequeues         uint64        message                          Transactional messages dequeued
+    msgPersistEnqueues     uint64        message                          Persistent messages enqueued
+    msgPersistDequeues     uint64        message                          Persistent messages dequeued
+    msgDepth               uint32        message                          Current size of queue in messages
+    msgDepthHigh           uint32        message                          Current size of queue in messages (High)
+    msgDepthLow            uint32        message                          Current size of queue in messages (Low)
+    byteTotalEnqueues      uint64        octet                            Total messages enqueued
+    byteTotalDequeues      uint64        octet                            Total messages dequeued
+    byteTxnEnqueues        uint64        octet                            Transactional messages enqueued
+    byteTxnDequeues        uint64        octet                            Transactional messages dequeued
+    bytePersistEnqueues    uint64        octet                            Persistent messages enqueued
+    bytePersistDequeues    uint64        octet                            Persistent messages dequeued
+    byteDepth              uint32        octet                            Current size of queue in bytes
+    byteDepthHigh          uint32        octet                            Current size of queue in bytes (High)
+    byteDepthLow           uint32        octet                            Current size of queue in bytes (Low)
+    enqueueTxnStarts       uint64        transaction                      Total enqueue transactions started
+    enqueueTxnCommits      uint64        transaction                      Total enqueue transactions committed
+    enqueueTxnRejects      uint64        transaction                      Total enqueue transactions rejected
+    enqueueTxnCount        uint32        transaction                      Current pending enqueue transactions
+    enqueueTxnCountHigh    uint32        transaction                      Current pending enqueue transactions (High)
+    enqueueTxnCountLow     uint32        transaction                      Current pending enqueue transactions (Low)
+    dequeueTxnStarts       uint64        transaction                      Total dequeue transactions started
+    dequeueTxnCommits      uint64        transaction                      Total dequeue transactions committed
+    dequeueTxnRejects      uint64        transaction                      Total dequeue transactions rejected
+    dequeueTxnCount        uint32        transaction                      Current pending dequeue transactions
+    dequeueTxnCountHigh    uint32        transaction                      Current pending dequeue transactions (High)
+    dequeueTxnCountLow     uint32        transaction                      Current pending dequeue transactions (Low)
+    consumers              uint32        consumer                         Current consumers on queue
+    consumersHigh          uint32        consumer                         Current consumers on queue (High)
+    consumersLow           uint32        consumer                         Current consumers on queue (Low)
+    bindings               uint32        binding                          Current bindings
+    bindingsHigh           uint32        binding                          Current bindings (High)
+    bindingsLow            uint32        binding                          Current bindings (Low)
+    unackedMessages        uint32        message                          Messages consumed but not yet acked
+    unackedMessagesHigh    uint32        message                          Messages consumed but not yet acked (High)
+    unackedMessagesLow     uint32        message                          Messages consumed but not yet acked (Low)
+    messageLatencySamples  delta-time    nanosecond                       Broker latency through this queue (Samples)
+    messageLatencyMin      delta-time    nanosecond                       Broker latency through this queue (Min)
+    messageLatencyMax      delta-time    nanosecond                       Broker latency through this queue (Max)
+    messageLatencyAverage  delta-time    nanosecond                       Broker latency through this queue (Average)
+Method 'purge' Discard all messages on queue
+qpid: list queue
+Objects of type qpid.queue
+    ID    Created   Destroyed  Index
+    ===========================================================================
+    1012  21:08:13  -          1002.pub_start
+    1014  21:08:13  -          1002.pub_done
+    1016  21:08:13  -          1002.sub_ready
+    1018  21:08:13  -          1002.sub_done
+    1020  21:08:13  -          1002.perftest0
+    1038  21:09:08  -          1002.mgmt-3206ff16-fb29-4a30-82ea-e76f50dd7d15
+    1040  21:09:08  -          1002.repl-3206ff16-fb29-4a30-82ea-e76f50dd7d15
+    1046  21:09:32  -          1002.mgmt-df06c7a6-4ce7-426a-9f66-da91a2a6a837
+    1048  21:09:32  -          1002.repl-df06c7a6-4ce7-426a-9f66-da91a2a6a837
+    1054  21:10:01  -          1002.mgmt-c55915c2-2fda-43ee-9410-b1c1cbb3e4ae
+    1056  21:10:01  -          1002.repl-c55915c2-2fda-43ee-9410-b1c1cbb3e4ae
+    1063  21:26:00  -          1002.mgmt-8d621997-6356-48c3-acab-76a37081d0f3
+    1065  21:26:00  -          1002.repl-8d621997-6356-48c3-acab-76a37081d0f3
+qpid: list 1020
+Object of type qpid.queue: (last sample time: 21:26:02)
+    Type    Element                1020
+    ==========================================================================
+    config  vhostRef               1002
+    config  name                   perftest0
+    config  durable                False
+    config  autoDelete             False
+    config  exclusive              False
+    config  arguments              {'qpid.max_size': 0, 'qpid.max_count': 0}
+    config  storeRef               NULL
+    inst    msgTotalEnqueues       500000 messages
+    inst    msgTotalDequeues       500000
+    inst    msgTxnEnqueues         0
+    inst    msgTxnDequeues         0
+    inst    msgPersistEnqueues     0
+    inst    msgPersistDequeues     0
+    inst    msgDepth               0
+    inst    msgDepthHigh           0
+    inst    msgDepthLow            0
+    inst    byteTotalEnqueues      512000000 octets
+    inst    byteTotalDequeues      512000000
+    inst    byteTxnEnqueues        0
+    inst    byteTxnDequeues        0
+    inst    bytePersistEnqueues    0
+    inst    bytePersistDequeues    0
+    inst    byteDepth              0
+    inst    byteDepthHigh          0
+    inst    byteDepthLow           0
+    inst    enqueueTxnStarts       0 transactions
+    inst    enqueueTxnCommits      0
+    inst    enqueueTxnRejects      0
+    inst    enqueueTxnCount        0
+    inst    enqueueTxnCountHigh    0
+    inst    enqueueTxnCountLow     0
+    inst    dequeueTxnStarts       0
+    inst    dequeueTxnCommits      0
+    inst    dequeueTxnRejects      0
+    inst    dequeueTxnCount        0
+    inst    dequeueTxnCountHigh    0
+    inst    dequeueTxnCountLow     0
+    inst    consumers              0 consumers
+    inst    consumersHigh          0
+    inst    consumersLow           0
+    inst    bindings               1 binding
+    inst    bindingsHigh           1
+    inst    bindingsLow            1
+    inst    unackedMessages        0 messages
+    inst    unackedMessagesHigh    0
+    inst    unackedMessagesLow     0
+    inst    messageLatencySamples  0
+    inst    messageLatencyMin      0
+    inst    messageLatencyMax      0
+    inst    messageLatencyAverage  0
+qpid:
+
+ +

You get the idea... have fun!

+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Multiple AMQP Version Support.html b/documentation/content/xdocs/Multiple AMQP Version Support.html new file mode 100755 index 0000000000..22a1c09801 --- /dev/null +++ b/documentation/content/xdocs/Multiple AMQP Version Support.html @@ -0,0 +1,192 @@ + + + Apache Qpid : Multiple AMQP Version Support + + + + + + + + + +
+
+ + Apache Qpid : Multiple AMQP Version Support + +
+
+ This page last changed on Oct 30, 2006 by kpvdr. +
+ +
+
+

Multiple-AMQP Version Support in Qpid

+

This page describes an effort to allow multiple AMQP versions to be supported in the broker. This implies:

+
    +
  • that a broker will be able to accept a connection from clients requesting a variety of versions of the AMQ protocol;
    • +
  • The versions to be supported in this manner are determined at compile time;
    • +
  • A code generator generates the framing classes directly from the XML specification file(s), allowing generated classes to support any of the supported versions.
    • +
  • Each of these classes need only the major and minor version numbers at instantiation to represent a frame from that protocol version.
    • +
+ + +

The thinking behind the following generator description is described in AMQPVersion.1. Option 3 (Intelligent Generation) was selected for this implementation.

+ +

1. Current Generator Status

+

The Java generator is more-or-less complete and has been checked into subversion under the gentools directory for initial review. It has not been integrated into the Qpid project as yet; I would like to complete the C++ generation first. However, while the C++ work is in progress, the Java generator is available for review and comment. For instructions on installing and running, see the README file in the gentools directory.

+ +

2. Generator Description

+

2.1. Overview

+

The generator first reads in all the listed specification files and constructs from them a memory model (structure) of the specifications "superimposed" on top of each other so that the differences between them are easy to determine. A domain map (which maps all domain names to their simple domain types) is also constructed.

+ +

The generator then uses the model to perform code generation. This is achieved by using templates which contain the static parts of the code (which are simply reproduced) and in which are embedded tokens. These tokens, when encounted in the template, are passed on to the generator class, which then uses the context and model to generate specific the version-dependent sections of the code.

+ +

Both of these are discussed in more detail below.

+ +

2.2. AMQP verion model

+

The memory model has two parts - the domain map and the model (specification structure) itself.

+ +

Domain Map

+ +

The domain map is a two-level map. The lowest level maps the simple domain types to the AMQP versions in which they are defined. The upper level maps the domain names to the simple domain type.

+ +

In the following hypothetical example, the class-id domain is changed from short in v.0.8 to long in v.0.9, then back to short in v.0.10. The queue-type domain was introduced in v.0.10, while the redirected was removed in v0.9.

+
+
access-ticket --- shortstr --- V[0.8, 0.9, 0.10]
+
+class-id -+------ short ------ V[0.8, 0.10]
+          +------ long ------- V[0.9]
+
+queue-type ------ shortstr --- V[0.10]
+
+redirected ------ bit -------- V[0.8]
+
+
+ +

A simplified version of the object model is as follows:

+
Domain Map class diagram
+

+
+ +

Specification Model

+ +

The specification model consists of a series of embedded maps in the same logical structure as the XML specification elements themsleves: the model contains a map of class maps; class maps contain field and method maps; method maps contain field maps. At the lowest level, there is a map to a set of AMQP versions.

+ +

The following illustrates a small portion of a model.
+The Access class has an index of 30 for versions 0.8 - 0.10. The request method has index 10 in v.0.8 and 0.9, but was changed to 20 in v.0.10. This method has a active field in ordinal 1 and a realm field in ordinal 0 for all versions. The realm field is of domain path for version 0.8, but was changed to domain shortstr in versions 0.9 ans 0.10. NOTE: The domains in this model are the domain names, not the domain types. The Domain Map above is used to look up the domain type.

+
+
C Access -+---- I 30 ---------- V[0.8, 0.9, 0.10]
+          +---- M request -+-+- I 10 -------- V[0.8, 0.9]
+                           | +- I 20 -------- V[0.10]
+                           +-+- F active --+- O 1 ---------- V[0.8, 0.9, 0.10]
+                             |             +- D bit -------- V[0.8, 0.9, 0.10]
+                             +- F realm -+--- O 0 ---------- V[0.8, 0.9, 0.10]
+                                         +-+- D path ------- V[0.8]
+                                           +- D shortstr --- V[0.9, 0.10]
+
+C = class; M = method; F = field; D = domain name; I = index; O = ordinal; V = version(s)
+
+
+ +

An ordinal is the index number of a field implied by its relative position in the XML specification file. The first field in a class or method has ordinal 0, the second ordinal 1, etc.

+ +

A simplified version of the object model is as follows:

+
Model class diagram
+

+
+ +

Generation

+ +

The Generator itself consists of a template passer and large number of code-generating methods for handling the various tokens that are embedded in the templates.

+ +

Templates contain three types of tokens:

+
    +
  1. Filename tokens, which determine the name of the file to be generated;
    2. +
  2. Simple Class/Method/Field replacement tokens in which the name of these elements are used to replace the token (e.g. "${CLASS}${METHOD}Body" becomes "BasicConsumeBody");
    3. +
  3. List tokens, in which a code snippet is generated once for each item in the list. A second token on the same line determines the code snippet that will be generated. The list tokens cannot be combined or embedded within each other. There are four list tokens: +
      +
    1. %{VLIST} which generates once per version;
      2. +
    2. %{CLIST} which generates once per class;
      3. +
    3. %{MLIST} which generates once per method;
      4. +
    4. %{FLIST} which generates once per field.
      5. +
    +
    4. +
+ + +

3. Code Generation

+

3.1. Difference Modes

+

The following changes may take place between one version and the next:

+
    +
  • Addition of classes, methods, fields or domains;
    • +
  • Deletion of classes, methods, fields or domains;
    • +
  • Modification of field domains or domain types;
    • +
  • Modification of the ordinal position of fields;
    • +
  • Modification of the index of classes or methods;
    • +
+ + +

3.2 Java Generation

+

3.2.1. MethodBody classes

+

MethodBody classes here.

+ +

3.2.2. PropertyContentHeader classes

+

PropertyContentHeader classes here.

+ +

3.2.3. Registry classes

+

Registry classes here.

+ +

3.3. C++ Generation

+

Watch this space...

+ +
+
+ Attachments: +
+ +
+ + AmqpDomainMap.png (image/png) +
+ + AmqpDomainMap.png (image/png) +
+ + AmqpModel.png (image/png) +
+
+ +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Multiple AMQP Version Support_attachments/AmqpDomainMap.png b/documentation/content/xdocs/Multiple AMQP Version Support_attachments/AmqpDomainMap.png new file mode 100755 index 0000000000..9415923f6f Binary files /dev/null and b/documentation/content/xdocs/Multiple AMQP Version Support_attachments/AmqpDomainMap.png differ diff --git a/documentation/content/xdocs/Multiple AMQP Version Support_attachments/AmqpModel.png b/documentation/content/xdocs/Multiple AMQP Version Support_attachments/AmqpModel.png new file mode 100755 index 0000000000..5282c8d2ec Binary files /dev/null and b/documentation/content/xdocs/Multiple AMQP Version Support_attachments/AmqpModel.png differ diff --git a/documentation/content/xdocs/Navigation.html b/documentation/content/xdocs/Navigation.html new file mode 100755 index 0000000000..ff44323cb8 --- /dev/null +++ b/documentation/content/xdocs/Navigation.html @@ -0,0 +1,77 @@ + + + Apache Qpid : Navigation + + + + + + + + + +
+
+ + Apache Qpid : Navigation + +
+
+ This page last changed on Apr 15, 2008 by ritchiem. +
+ +
+

+ +

Apache Qpid

+

Home
+ People
+ Project Status

+ +

Download
+ Getting Started
+ Mailing Lists
+ License

+ +

Resources

+

Getting Involved
+ Source Repository
+ Building Qpid

+ +

Issue Reporting
+ Developer Pages
+ Acknowledgment

+ +

About AMQP

+

What is the AMQProtocol?

+ +

AMQProtocol Specification Download

+ +

+
+ +
+
+ Attachments: +
+ +
+ + AMQP_logo_71px-small.jpg (image/jpeg) +
+ + apache-incubator-logo-small.png (image/png) +
+
+ +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Navigation_attachments/AMQP_logo_71px-small.jpg b/documentation/content/xdocs/Navigation_attachments/AMQP_logo_71px-small.jpg new file mode 100755 index 0000000000..655766e3fc Binary files /dev/null and b/documentation/content/xdocs/Navigation_attachments/AMQP_logo_71px-small.jpg differ diff --git a/documentation/content/xdocs/Navigation_attachments/apache-incubator-logo-small.png b/documentation/content/xdocs/Navigation_attachments/apache-incubator-logo-small.png new file mode 100755 index 0000000000..e16f3f90eb Binary files /dev/null and b/documentation/content/xdocs/Navigation_attachments/apache-incubator-logo-small.png differ diff --git a/documentation/content/xdocs/NeverUseStaticLocalVariables.html b/documentation/content/xdocs/NeverUseStaticLocalVariables.html new file mode 100755 index 0000000000..1a3b73b9fd --- /dev/null +++ b/documentation/content/xdocs/NeverUseStaticLocalVariables.html @@ -0,0 +1,48 @@ + + + Apache Qpid : NeverUseStaticLocalVariables + + + + + + + + + +
+
+ + Apache Qpid : NeverUseStaticLocalVariables + +
+
+ This page last changed on Oct 19, 2006 by mmccorma. +
+ +

Never do this:

+
+
void f() {
+  static int x = 10;
+}
+
+ +

Static on a local variable means the compiler is supposed initialize it the first time the function is entered, but it holds its value on subsequent calls. It's sometimes used for local counters, or in the "Myers Singleton" approach to singletons.

+ +

The problem is that the C++ standard does not require compilers to make this initialization thread safe, and almost none do. So in a multi threaded program if there are concurrent first calls to f there will be a disaster. Using this for singletons is particularly prone to multi-threaded collisions.

+ +

So use the less elegant but safer options: make the variable a class member for member functions or a file-private global for non-member functions.

+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/NoUsingNamespaceInHeaders.html b/documentation/content/xdocs/NoUsingNamespaceInHeaders.html new file mode 100755 index 0000000000..7545bbfdd3 --- /dev/null +++ b/documentation/content/xdocs/NoUsingNamespaceInHeaders.html @@ -0,0 +1,49 @@ + + + Apache Qpid : NoUsingNamespaceInHeaders + + + + + + + + + +
+
+ + Apache Qpid : NoUsingNamespaceInHeaders + +
+
+ This page last changed on Oct 19, 2006 by mmccorma. +
+ +

Don't use the{{using namespace ...}} or using ... constructs in a header file. It might save you some typing but it also forces the namespaces you use onto every .cpp file that directly or indirectly includes your headers. That could create name clashes with names in some other namespace that the author of the .cpp file wants to use. Use fully qualified names, painful as it might be.

+ +

There is one exception. It's sometimes handy to "import" names from one namespace to another. For example suppose some C++ compiler doesn't provide the std::tr1::auto_ptr template, which is used in qpid. Boost does provide a compatible boost::auto_ptr but it's in the boost namespace and qpid expects it in std::tr1. No problem, we create our own tr1/memory header file:

+ +
+
#include <boost/memory>
+namespace std { 
+  namespace tr1 {
+    using boost::auto_ptr;
+  }
+}
+
+ +

This makes the boost template available in the standard namespace. (Actually you don't need to do this yourself, boost provides a set of adapter headers for all the tr1 stuff.)

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/OSVC.html b/documentation/content/xdocs/OSVC.html new file mode 100755 index 0000000000..11986b7480 --- /dev/null +++ b/documentation/content/xdocs/OSVC.html @@ -0,0 +1,137 @@ + + + Apache Qpid : OSVC + + + + + + + + + +
+
+ + Apache Qpid : OSVC + +
+
+ This page last changed on Apr 11, 2008 by cctrieloff. +
+ +

A RHEL4 Grimoire

+ +

by Michael Goulish on this 11th day of April, 2008

+ +

Introduction

+ +

Programmer! Turn back now, if you can, to the daylit world!

+ +

But if you must walk this road - take with you this map! Do not stray into the mires and pits where I have wandered and despaired.

+ +

Herein I will describe what I can of the perils I have encountered in the antique land of RHEL4.

+ +

Iterators and the "->" operator.

+ +

I believe this is a compiler problem with the -> operator, in the neighborhood of any kind of iterators.

+ +

Code like this will not compile:

+
+
ConsumerImplMap::iterator i = consumers.find(delivery.getTag());
+
+if (i != consumers.end())
+{  get_pointer(i)->acknowledged(delivery); // <--- Bad!  }
+
+ +

Do this instead:

+
+
ConsumerImplMap::iterator i = consumers.find(delivery.getTag());
+
+if (i != consumers.end())
+{  (*i).second->complete(delivery); // <--- Good!  }
+
+ +

( Thanks, Kim! )

+ +

Don't use BOOST_FIXTURE_TEST_CASE

+ +

Because it Doesn't Exist.

+ +

All it does is allow you to use a class (or struct) declaration in many test cases without declaring it in every one.

+ +

So what? Big deal! Just declare your structure in each test case, and use the QPID_AUTO_TEST_CASE macro instead!

+ +

If you have this struct:

+
+
struct ClientSessionFixture : public Foo
+{  int bar;  }
+
+ +

Don't do this:

+
+
BOOST_FIXTURE_TEST_CASE(testQueueQuery, ClientSessionFixture)
+{  bar = 666;  BOOST_CHECK_EQUAL ( bar, 666 );  }
+
+ +

Do do this:

+
+
QPID_AUTO_TEST_CASE(testQueueQuery)
+{  ClientSessionFixture fix;  fix.bar = 666;  BOOST_CHECK_EQUAL ( fix.bar, 666 );  }
+
+ +

(Thanks, Alan!)

+ +

Don't use the BOOST_TEST macros !

+ +

If you are tempted to use

+
+
BOOST_AUTO_TEST_SUITE, or
+
+BOOST_AUTO_TEST_CASE, or
+
+BOOST_AUTO_TEST_SUITE_END,
+
+

dont!

+ +

Use instead:

+
+
QPID_AUTO_TEST_SUITE, or
+
+QPID_AUTO_TEST_CASE, or
+
+QPID_AUTO_TEST_SUITE_END !
+
+

They turn into Appropriate Things depending on the version of Boost you are using.

+ +

Sometimes the Appropriate Thing is whitespace...

+ +

(Thanks, Alan and Kim !)

+ +

Don't use boost::iostreams.

+ +

They don't exist.

+
+
/usr/include/boost/iostreams/: No such file or directory
+
+

Instead, use low-level Unix IO, from the Dawn of Time.

+
+
open()
+
+read()
+
+write()
+
+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Old Clustering Design Note.html b/documentation/content/xdocs/Old Clustering Design Note.html new file mode 100755 index 0000000000..59e425533f --- /dev/null +++ b/documentation/content/xdocs/Old Clustering Design Note.html @@ -0,0 +1,185 @@ + + + Apache Qpid : Old Clustering Design Note + + + + + + + + + +
+
+ + Apache Qpid : Old Clustering Design Note + +
+
+ This page last changed on Mar 08, 2007 by aconway. +
+ +

Overview

+ +

The following is a proposal for the design of a clustering solution to increase the scalability of the Qpid AMQP broker by allowing multiple broker processes to collaborate to provide services to application clients connected to any one of these processes. By spreading the connections across different processes more clients can be supported.

+ +

Terms & Definitions

+ +

A cluster consists of any number of brokers in a fixed order. Each broker in the cluster has a unique name. All brokers in the cluster know the set of brokers in their cluster and agree on the ordering of those brokers. The first broker in the cluster is the leader; all brokers agree on the current leader. The mechanisms for achieving and maintaining this structure will be described below.

+ +

Each client is connected to one broker in the cluster, to whom it sends its requests in the same way it would were it connected to a broker that was not part of a cluster. Clients that implement the AMQP specification should be able to work with a clustered broker unaltered. However, when in a cluster, a broker will need to alter its response to certain client requests. An objective of the design is to minimise the scope and complexity of this altered behaviour.

+ +

Brokers in a cluster all connect to each other. Though one socket between any two brokers would suffice, it is simpler to implement if we assume that each broker will be a client of each other broker. Thus there will in fact be two connections between any two members, one in each 'direction'. This way we can reuse as much of a non-clustered brokers behaviour as possible.

+ +

A broker will need to distinguish between sessions with an application client and sessions where the 'client' of the socket in a session is actually another broker.

+ +

Outline of Approach for Clustering

+ +

Stated simply, the cluster will:

+ +
    +
  • replicate exchanges by broadcasting the original Exchange.Declare and Exchange.Delete messages to all members of the cluster.
    • +
+ + +
    +
  • replicate queues by broadcasting the original Queue.Declare and Queue.Delete messages to all members of the cluster
    • +
+ + +
    +
  • replicate bindings by broadcasting Queue.Bind messages to all members of the cluster
    • +
+ + +
    +
  • relay messages from a copy of an exchange in one broker to the equivalent exchange in another broker where necessary to ensure that consumers on any broker in the cluster receive messages that are published to any broker in the cluster
    • +
+ + +

Private queues exist in real form in only one broker; the broker that receives the original declaration from a client. All the other brokers in the cluster set up a proxy for this queue. This proxy can be bound to exchanges as a normal queue can, but whenever a message is routed to it, that message is simply relayed on to the broker in which the real queue exists. However, though multiple queue proxies may exist with the same target member, if these are bound such that all of them match a given message, only one copy of that message should be relayed to the target member.

+ +

Copies of shared queues will exist at each broker in the cluster. These are bound to exchanges as usual and can have consumers registered with them. In addition to consumers from the application clients, these shared queue copies track the number of consumer for that queue that are held on other brokers. They use this information to fairly distribute messages between all consumers.

+ +

The clustering in general involves propagation of certain methods received by one broker in the cluster from a client to all the other cluster members. Specifically those methods concerned with the setup of routing information are propagated allowing all members of the cluster to play their part in the routing of messages from and to clients distributed across the cluster.

+ +

In particular the cluster will propagate all Exchange.Declare, Exchange.Delete, Queue.Declare, Queue.Delete and Queue.Bind messages. It will also propagate Basic.Consume and Basic.Cancel messages that refer to shared queues.

+ +

The propagation can be carried out synchronously or asynchronously with respect to the original client request. In other words the broker that receives one of these messages from a client will send an equivalent message to the other brokers and can then wait until it receives responses from these brokers before it sends the confirmation message back to the client. Alternatively it could return a response to the client immediately. A hybrid approach could also be used. In general the originating broker waits for n responses, where 0 < n < number of members in the cluster. The value of n to be used will be set through policies to achieve the required latency v. consistency trade offs for a particular situation.
+Cluster Management

+ +

As mentioned above the cluster is defined to be an agreed set of member brokers in an agreed order. This helps reasoning about consistency. The 'first' member of the group acts as the leader and issues authoritative statements on who is in or out of the cluster. All brokers in the cluster store the last received membership announcement from which they can infer the current leader.

+ +

Ordering is maintained by requiring that new members join through the leader. A prospective new member can connect to any other member in the cluster, but these other members should pass on the join request to the leader.

+ +

Once connected to a member of the group the new member issues a join request, to which the leader responds by sending a new membership announcement to all members including the new member. It will also initiate the replay messages required to replicate cluster state to the new member; the other cluster members also participate in this message replay. Once it has processed all the replayed messages and is therefore up to date with respect to cluster state, the new member can start accepting client connections.

+ +

State is transferred through (a) Exchange.Declare methods for all exchanges, (b) Queue.Declare messages for all queues, (c) Queue.Bind requests for all queue bindings in all exchanges and (d) Basic.Consume requests for all consumers of shared queues at each node. The leader is responsible for replicating all exchanges, shared queues and their bindings. Other members are responsible for replicating private queues hosted by them and the bindings for these queues as well as consumer counts for shared queues. The replay of messages from the leader must be processed before those from other cluster members (as e.g. bindings for private queues require that the exchanges have already been declared). The completion of the required replay of messages from a broker is signaled by a Cluster.Synch message. Messages received after this are 'live' messages received through the receiving broker being treated as a normal member.

+ +

Failure of a broker may be detected by any other broker in the cluster in the course of trying to communicate with that broker. Failures are handled by sending a suspect message to the leader of the cluster, who verifies the suspected broker is down and issues a new announcement of membership, with the failed broker removed if the failure is verified. In addition to discovery of failure during normal communication, each broker member is responsible for periodically pinging the 'previous' broker (i.e. the broker that occurs just before itself in the ordered membership list). The leader will assume responsibility for pinging the last member to join the group.

+ +

The leader may itself fail. This may be detected by the next broker in the list, in which case that broker responds by assuming leadership and sending an announcement of the new membership list with the old leader removed. It may also be detected by other brokers. As they cannot send a suspect warning to the leader, they send it to the broker next to the leader.
+Message Handling Changes and Protocol Extensions

+ +

To incorporate clustering while reusing the same communication channel for intra-cluster communications and extension to the protocol is proposed. It is not necessary for clients to know about this extension so it has no impact on the compliance of the broker and can be treated as a proprietary extension for Qpid. The extension consists of a new class of messages, Cluster, which has the following methods:

+ +

Cluster.Join

+ +

Sent by a new member to the leader of the cluster to initiate the joining process. On receiving a join the leader will try to establish its own connection back to the new member. It will then send a membership announcement and various messages to ensure the new member has the required state built up.

+ +

Cluster.Membership

+ +

Sent by the leader of the cluster whenever there is a change in the membership of the cluster either through a new broker joining or through a broker leaving or failing. All brokers should store the membership information sent. If they are waiting for responses from a member that is no longer part of the cluster they can handle the fact that that broker has failed. If it contains a member to whom they have not connected they can connect (or reconnect).

+ +

Cluster.Leave

+ +

Sent to the leader by a broker that is leaving the cluster in an orderly fashion. The leader responds by sending a new membership announcement.

+ +

Cluster.Suspect

+ +

Sent by brokers in the cluster to the leader of the cluster to inform the leader that they suspect another member has failed. The leader will attempt to verify the falure and then issue a new Cluster.Membership message excluding the suspected broker if it has failed leaving it in if it seems to be responding.

+ +

Cluster.Synch

+ +

Sent to complete a batch of message replayed to a new member to allow it to build up the correct state.

+ +

Cluster.Ping

+ +

Sent between brokers in a cluster to give or request a heart beat and to exchange information about loading. A ping has a flag that indicates whether it expects a response or not. On receiving a ping a broker updates its local view of the load on that server and if required sends its own ping in response.

+ +

In addition to this new class, the handling of the following is also altered. The handling of each message may depend on whether it is received from an application client or from another broker.

+ +

Connection.Open

+ +

A broker needs to detect whether the open request is from an application client or another broker in the cluster. It will use the capabilities field to do this; brokers acting as clients on other brokers require the 'cluster-peer' capability.

+ +

If a broker receives a Connection.Open from an application client (i.e. if the cluster-peer capability is not required) it may issue a Connection.Redirect if it feels its loading is greater than the loading of other members in the cluster.

+ +

Exchange.Declare

+ +

On receiving this message a broker propagates it to all other brokers in the cluster, possibly waiting for responses before responding with an Exchange.Declare-Ok.

+ +

Queue.Declare

+ +

On receiving this message a broker propagates it to all other brokers in the cluster, possibly waiting for responses before responding with a Queue.Declare-Ok.

+ +

Queue.Bind

+ +

Again, this is replicated to all other brokers, possibly waiting for responses before sending back a Queue.Bind-Ok to the client.

+ +

Queue.Delete

+ +

On receiving this message a broker propagates it to all other brokers in the cluster, optionally waiting for responses before responding to the client.

+ +

Basic.Consume

+ +

If the consume request is for a private queue, no alteration to the processing is required. However, if it is for a shared queue then the broker must additionally replicate the message to all other brokers.

+ +

Basic.Cancel

+ +

If the cancel request is for a subscription to a private queue, no alteration to the processing is required. However, if it is for a shared queue then the broker must additionally replicate the message to all other brokers.

+ +

Basic.Publish

+ +

The handling of Basic.Publish only differs from the non-clustered case where (a) it ends up in a shared queue or (b) it ends up in a 'proxy' for a private queue that is hosted within another member of the cluster.

+ +

When the published message ends up in a shared queue, the broker must be aware of whether the message was published to it by another broker or by an application client. Messages that come from other brokers are dispatched to the local brokers own application client subscribers. Messages that come from application clients are either dispatched to the next application client or relayed to another broker. A round-robin scheme applies here where each subscriber, whether a 'real' subscriber or a consumer in a relay link to another broker, gets its 'turn'.

+ +

In other words the allocation of a message to a consumer on a shared queue happens at the first broker to receive the publish request from the application. All brokers signal their local consumer count by propagating the Basic.Consume (and Basic.Cancel) messages they receive from clients so each broker has a local view of the cluster wide distribution of consumers which can be used to achieve a fair distribution of messages received by that broker.

+ +

As each broker can receive messages from the application, strict round-robin delivery is not guaranteed, but in general a fair distribution will result. Brokers should remember the next consumer to receive messages from the application and also the next consumer to receive messages from the cluster.

+ +

A local broker's view of consumer distribution is updated asynchronously with respect to message publishing and dispatch. This means that the view might be stale with regard to the remote consumer counts when the next consumer for a message is determined. It is therefore possible that one broker directs a message to a broker that it thinks has a consumer, but when that message arrives at the remote broker the consumer has disconnected. How this is handled should be controlled through different policies: pass it on to another broker, possibly with the redelivered flag set (particularly if it goes back to the broker it came from), discard the message or hold on to it for a finite period of time and deliver it to any application consumer that subscribes in that time.

+ +

The situation just described is essentially the same situation as in a non-clustered case where a consumer disconnects after a message has been sent to it, but before it has processed that message. Where acknowledgements aren't used the message will be lost, where acknowledgements or transactions are used the message should be redelivered, possible out of sequence. Of course in the clustered case there is a wider window in which this scenario can arise.

+ +

Where the messages is delivered to a proxied private queue, that message is merely relayed on to the relevant broker. However, It is important that where more than one proxied queue to the same target broker are bound to the same exchange, the message only be relayed once. The broker handling the Basic.Publish must therefore track the relaying of the message to its peers.

+ +

Failure Analysis

+ +

As mentioned above, the primary objective of this phase of the clustering design is to enable the scaling of a system by adding extra broker processes that cooperate to serve a larger number of clients than could be handle by one broker.

+ +

Though fault tolerance is not a specific objective yet, the cluster must allow for the failure of brokers without bringing the whole system to a halt.

+ +

The current design (and implementation) only handles process failures entirely satisfactorily. Network failures* result in the exclusion of brokers from the cluster and will behave reasonably only where the view of reachability is consistent across the cluster. Network partitions between the cluster nodes will result in independent clusters being formed and there is currently no provision for merging these once the partition heals.

+ +
    +
  • failures here means anything that causes a tcp stream to fail; a relatively straightforward improvement would be to buffered unacknowledged requests that have been broadcast allowing attempts to re-establish a tcp connection on failure and replaying the messages (assuming idempotent messages)
    • +
+ + +

The group abstraction described above does not provide virtual synchrony. When a broker fails while performing a broadcast to the group, the result will not be uniform across the other members. Where synchronous propagation is used, the client will be ware of this state as it will not have received the response from the broker and will reissue the request on failing over to another broker. (The current failover as implemented in the Qpid client will actually recreate all state required by the client).

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/People.html b/documentation/content/xdocs/People.html new file mode 100755 index 0000000000..887fcc4a77 --- /dev/null +++ b/documentation/content/xdocs/People.html @@ -0,0 +1,110 @@ + + + Apache Qpid : People + + + + + + + + + +
+
+ + Apache Qpid : People + +
+
+ This page last changed on Apr 12, 2008 by cctrieloff. +
+ +

Apache Qpid Committers

+ +

The people listed below have made significant contributions to Qpid by working long and hard to make quality software for the rest of the world to use.

+ +

In addition to providing us contribuions, or being commmitters some of the following people are also members of the Project Management Committee (PPMC - as we are still in incubator). Refer to the How the ASF works for details on meritocracy.

+ +

If you would like to contribute to Qpid please look at the Get Involved page to see how you can contribute.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Aidan SkinnerAlan ConwayArnaud SimonAndrew Stitcher
Carl TrieloffGordon SimJim MeyeringJohn O'Hara
Kim van der RietMarnie McCormackMartin RitchieNuno Santos
Paul FremantleRafael SchlomingRajith AttapattuRobert Godfrey
Robert GreigRupert SmithYoav Shapira 
+ +

Many thanks to the following people for providing contributions:

+ + + + + + + + + + + + + + +
Colin CristBhupendra BhardwajKevin SmithSteve Vinoski
Steven ShawTomas Restrepo  
+ +

And many thanks to our project's mentors:

+ + + + + + + + + + + + + + +
Cliff SchmidtPaul FremantleYoav ShapiraScott Deboy
Criag Russel   
+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Performance Testing for C++.html b/documentation/content/xdocs/Performance Testing for C++.html new file mode 100755 index 0000000000..5cc78d9146 --- /dev/null +++ b/documentation/content/xdocs/Performance Testing for C++.html @@ -0,0 +1,155 @@ + + + Apache Qpid : Performance Testing for C++ + + + + + + + + + +
+
+ + Apache Qpid : Performance Testing for C++ + +
+
+ This page last changed on Apr 15, 2008 by cctrieloff. +
+ +

How to measure performance of my hardware

+ +

Overview

+ +

Brief page on how to get perf data for your configuration. Note that per data is affected greatly by hardware, and OS tuning. So tune your OS and baseline your hardware. You should be able to get perftest 'below' to within 5%-8% of the max for the baseline of a well setup config. If you can't - welcome to mail the list.

+ +

Basic tuning

+ +

Tuning will increase your throughput and increase your determinism. The simple things are turn off cpuspeed, irqbalance etc and set timer resolution for the processors you use.... All the standard stuff.

+ +

Sample Data

+ +

Some sample results running on the out of date lump in the corner, running on current hardware you should easily beat these.

+ +

1K block Size

+ + + + + + + + + + + + + + + +
clients pubs/sec subs/sec transfers/sec Mbytes/sec
     
+

..

+ +

more data. to illustrate point .... TODO

+ +

...

+ +

Note that there will be two limits, one is the size of the pipe, the other will be how many IO's per-second the hardware can do. On small messages 64bytes or less you will hit the IO limit, on larger messages you will hit the network bandwidth, then scale with more NICs. You can get more 'batch' if you like to get the number up when you hit the IO's per second limit with AMQP-0-10 sync points etc... play with perftest + baseline tools like netperf.

+ +

The following tool is including, or can be located in 'cpp/src/tests/' Run with --help to check the options on the latest version.

+
+
$ ./perftest --help
+
+N4qpid7Options9ExceptionE: Test Options:
+  -h [ --host ] HOST (localhost)       Broker host to connect to
+  -b [ --broker ] HOST (localhost)     Broker host to connect to
+  -p [ --port ] PORT (5672)            Broker port to connect to
+  -v [ --virtualhost ] VHOST           virtual host
+  -n [ --clientname ] ID (cpp)         unique client identifier
+  --username USER (guest)              user name for broker log in.
+  --password USER (guest)              password for broker log in.
+  --help                               print this usage statement
+  --setup                              Create shared queues.
+  --control                            Run test, print report.
+  --publish                            Publish messages.
+  --subscribe                          Subscribe for messages.
+  --mode shared|fanout|topic (shared)  Test mode.
+                                       shared: --qt queues, --npubs publishers
+                                       and --nsubs subscribers per queue.
+
+                                       fanout: --npubs publishers, --nsubs subs
+                                       cribers, fanout exchange.
+                                       topic: --qt topics, --npubs publishers a
+                                       nd --nsubs subscribers per topic.
+
+  --npubs N (1)                        Create N publishers.
+  --count N (500000)                   Each publisher sends N messages.
+  --size BYTES (1024)                  Size of messages in bytes.
+  --pub-confirm yes|no (1)             Publisher use confirm-mode.
+  --durable yes|no (0)                 Publish messages as durable.
+  --unique-data yes|no (0)             Make data for each message unique.
+  --nsubs N (1)                        Create N subscribers.
+  --sub-ack N (0)                      N>0: Subscriber acks batches of N.
+                                       N==0: Subscriber uses unconfirmed mode
+  --qt N (1)                           Create N queues or topics.
+  --iterations N (1)                   Desired number of iterations of the test
+                                       .
+  -s [ --summary ]                     Summary output: pubs/sec subs/sec transf
+                                       ers/sec Mbytes/sec
+  --queue_max_count N (0)              queue policy: count to trigger 'flow to
+                                       disk'
+  --queue_max_size N (0)               queue policy: accumulated size to trigge
+                                       r 'flow to disk'
+  --interval_sub ms (0)                >=0 delay between msg consume
+  --interval_pub ms (0)                >=0 delay between msg publish
+
+Logging options:
+  --log-output FILE (stderr)  Send log output to FILE. FILE can be a file name
+                              or one of the special values:
+                              stderr, stdout, syslog
+  -t [ --trace ]              Enables all logging
+  --log-enable RULE (error+)  Enables logging for selected levels and component
+                              s. RULE is in the form 'LEVEL[+][:PATTERN]'
+                              Levels are one of:
+                               trace debug info notice warning error critical
+                              For example:
+                              '--log-enable warning+' logs all warning, error
+                              and critical messages.
+                              '--log-enable debug:framing' logs debug messages
+                              from the framing namespace. This option can be
+                              used multiple times
+  --log-time yes|no (1)       Include time in log messages
+  --log-level yes|no (1)      Include severity level in log messages
+  --log-source yes|no (0)     Include source file:line in log messages
+  --log-thread yes|no (0)     Include thread ID in log messages
+  --log-function yes|no (0)   Include function signature in log messages
+
+
+There are two ways to use perftest: single process or multi-process.
+
+If none of the --setup, --publish, --subscribe or --control options
+are given perftest will run a single-process test.
+For a  multi-process test first run:
+  perftest --setup <other options>
+and wait for it to complete. The remaining process should run concurrently::
+Run --npubs times: perftest --publish <other options>
+Run --nsubs times: perftest --subscribe <other options>
+Run once:          perftest --control <other options>
+Note the <other options> must be identical for all processes.
+
+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/PrivateLocking.html b/documentation/content/xdocs/PrivateLocking.html new file mode 100755 index 0000000000..9207dad803 --- /dev/null +++ b/documentation/content/xdocs/PrivateLocking.html @@ -0,0 +1,40 @@ + + + Apache Qpid : PrivateLocking + + + + + + + + + +
+
+ + Apache Qpid : PrivateLocking + +
+
+ This page last changed on Oct 19, 2006 by mmccorma. +
+ +

The only way to write thread safe code without losing your mind is to keep your synchronisation simple and small. You cannot test for thread safety. Really you can't. If synchronization is complicated or spread out it's pretty much impossible to know by inspection whether it's correct.

+ +

A key technique is to encapsulate synchronization inside thread-safe classes. Every public member function should protect itself from concurrent access by using private locks or other synchronization objects. You can verify the synchronization of just that class in isolation. It's much easier to build complicated thread-safe code from simple pieces that you know to be individually thread-safe.

+ +

It's very dangerous to provide public access to locks because now to establish thread safety for a class you have to inspect every potential use of that class. Not to mention every change to or addition of code using the class. Did I mention losing your mind?

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Project Status.html b/documentation/content/xdocs/Project Status.html new file mode 100755 index 0000000000..a3e511e0ba --- /dev/null +++ b/documentation/content/xdocs/Project Status.html @@ -0,0 +1,120 @@ + + + Apache Qpid : Project Status + + + + + + + + + +
+
+ + Apache Qpid : Project Status + +
+
+ This page last changed on Apr 12, 2008 by cctrieloff. +
+ +

+ +

Status

+ +

Qpid is an effort undergoing incubation at The Apache Software Foundation (ASF), sponsored by the Incubator PMC. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF

+ +

Project Incubation Status Page

+ +

Graduation

+ +

We are actively working toward graduation. In our last graduation vote we had thought that we needed a diverse committer base (which we have), however we came to learn that the PMC also needs good diversity (yes - thinking about this it is logical). So we stopped our graduation vote in order to add representation on our PPMC.

+ +

If you would like to become a committer and join the PPMC, this is how we do it. We would love to have you on the project!

+ +

Here is a copy of our current resolution:

+
+

WHEREAS, the Board of Directors deems it to be in the best
+ interests of the Foundation and consistent with the
+ Foundation's purpose to establish a Project Management
+ Committee charged with the creation and maintenance
+ of open-source software related to distributed messaging,
+ for distribution at no charge to the public.

+ +

NOW, THEREFORE, BE IT RESOLVED, that a Project Management
+ Committee (PMC), to be known as the "Apache Qpid Project",
+ be and hereby is established pursuant to Bylaws of the
+ Foundation; and be it further

+ +

RESOLVED, that the Apache Qpid Project be and hereby is
+ responsible for the creation and maintenance of software
+ related to distributed messaging; a multiple language
+ implementation providing daemons and APIs for publish &
+ subscribe, eventing and a wide range of message distribution patterns
+ based on the Advanced Message Queuing Protocol (AMQP) and
+ related technologies such as (transaction management, federation,
+ security, management); and be it further

+ +

RESOLVED, that the office of "Vice President, Qpid" be and
+ hereby is created, the person holding such office to serve at
+ the direction of the Board of Directors as the chair of the
+ Apache Qpid Project, and to have primary responsibility for
+ management of the projects within the scope of responsibility
+ of the Apache Qpid Project; and be it further

+ +

RESOLVED, that the persons listed immediately below be and
+ hereby are appointed to serve as the initial members of the
+ Apache Qpid Project:

+ +
    +
  • Alan Conway
    • +
  • Arnaud Simon
    • +
  • Carl Trieloff
    • +
  • Gordon Sim
    • +
  • John O'Hara
    • +
  • Marnie McCormack
    • +
  • Martin Ritchie
    • +
  • Paul Fremantle
    • +
  • Rajith Attapattu
    • +
  • Robert Greig
    • +
  • Robert Godfrey
    • +
  • Yoav Shapira
    • +
+ + +

NOW, THEREFORE, BE IT FURTHER RESOLVED, that
+ Carl Trieloff be appointed to the office of Vice President,
+ Qpid, to serve in accordance with and subject to the
+ direction of the Board of Directors and the Bylaws of the
+ Foundation until death, resignation, retirement, removal or
+ disqualification, or until a successor is appointed; and be it
+ further

+ +

RESOLVED, that all responsibility pertaining to the Qpid
+ encumbered upon the Apache Incubator be hereafter discharged.

+
+ +
+
+ Attachments: +
+ +
+ + apache-incubator-logo.png (image/png) +
+
+ +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Project Status_attachments/apache-incubator-logo.png b/documentation/content/xdocs/Project Status_attachments/apache-incubator-logo.png new file mode 100755 index 0000000000..81fb31ec71 Binary files /dev/null and b/documentation/content/xdocs/Project Status_attachments/apache-incubator-logo.png differ diff --git a/documentation/content/xdocs/Properties.xml b/documentation/content/xdocs/Properties.xml new file mode 100755 index 0000000000..1294d01468 --- /dev/null +++ b/documentation/content/xdocs/Properties.xml @@ -0,0 +1,124 @@ + + +
+ Explanation of System properties used in Qpid + + This page documents the various System Properties that are currently used in the Qpid Java code base. + +
+ Client Properties +
+ STRICT_AMQP + Default:FALSE + This forces the client to only send AMQP compliant frames. This will disable a number of JMS features. + + Features disabled by STRICT_AMQP + Queue Browser + Message Selectors + Durable Subscriptions + Session Recover may result in duplicate message delivery + Destination validation, so no InvalidDestinationException will be thrown + + This is associated with property STRICT_AMQP_FATAL +
+ +
+ STRICT_AMQP_FATAL + Default:FALSE + This will cause any attempt to utilise an enhanced feature to throw and UnsupportedOperationException. When set to false then the exception will not occur but the feature will be disabled. + + The Queue Browser will always show no messages. + Any message selector will be removed. + +
+ +
+ IMMEDIATE_PREFETCH + Default:FALSE + The default with AMQP is to start prefetching messages. However, with certain 3rd party Java tools, such as Mule this can cause a problem. Mule will create a consumer but never consume from it so any any prefetched messages will be stuck until that session is closed. This property is used to re-instate the default AMQP behaviour. The default Qpid behaviour is to prevent prefetch occurring, by starting the connection Flow Controlled, until a request for a message is made on the consumer either via a receive() or setting a message listener. +
+ + +
+ amq.dynamicsaslregistrar.properties + The name of the SASL configuration properties file. +
+ +
+ amqj.heartbeat.timeoutFactor + Float + The factor used to get the timeout from the delay between heartbeats +
+ +
+ amqj.tcpNoDelay + Default:TRUE + Disable Nagle's algorithm on the TCP connection. +
+ +
+ amqj.sendBufferSize + DEFAULT_BUFFER_SIZE = 32k + This is the default buffer sized created by Mina. +
+ +
+ amqj.receiveBufferSize + DEFAULT_BUFFER_SIZE = 32k + This is the default buffer sized created by Mina. +
+ +
+ amqj.protocolprovider.class + DEFAULT:org.apache.qpid.server.protocol.AMQPFastProtocolHandler + This specifies the default IoHandlerAdapter that represents the InVM broker. The IoHandlerAdapter must have a constructor that takes a single Integer that represents the InVM port number. +
+ +
+ jboss.host + Used by the JBossConnectionFactoryInitialiser to specify the host to connect to perform JNDI lookups. +
+ +
+ jboss.port + Used by the JBossConnectionFactoryInitialiser to specify the port to connect to perform JNDI lookups. +
+ +
+ + +
+ Management Properties + +
+ security + Default: null + String representing the Security level to be used to on the connection to the broker. The null default results in no security or PLAIN. When used with jmxconnector 'javax.management.remote.jmxmp.JMXMPConnector' a security value of 'CRAM-MD5' will result in all communication to the broker being encrypted. +
+ +
+ jmxconnector + Default: null + String representing the JMXConnector class used to perform the connection to the broker. The null default results in the standard JMX connector. Utilising 'javax.management.remote.jmxmp.JMXMPConnector' and security 'CRAM-MD5' will result in all communication to the broker being encrypted. +
+ +
+ timeout + Default: 5000 + Long value representing the milli seconds before connection to the broker should timeout. +
+
+ + +
+ Properties used in Examples + +
+ archivepath + Used in : FileMessageDispatcher + This property specifies the archive directory to move payload file(s) after a successful transfer. +
+
+ +
diff --git a/documentation/content/xdocs/PythonBrokerTest.html b/documentation/content/xdocs/PythonBrokerTest.html new file mode 100755 index 0000000000..94b1f0598b --- /dev/null +++ b/documentation/content/xdocs/PythonBrokerTest.html @@ -0,0 +1,66 @@ + + + Apache Qpid : PythonBrokerTest + + + + + + + + + +
+
+ + Apache Qpid : PythonBrokerTest + +
+
+ This page last changed on Oct 19, 2006 by mmccorma. +
+ +

Python Broker System Test Suite

+ +

This is a suite of python client tests that exercise and verify broker functionality. Python allows us to rapidly develop client test scenarios and provides a 'neutral' set of tests that can run against any AMQP-compliant broker.

+ +

The python/tests directory contains a collection of python modules, each containing several unittest classes, each containing a set of test methods that represent some test scenario. Test classes inheirt qpid.TestBas from qpid/testlib.py, it inherits unittest.TestCase but adds some qpid-specific setUp/tearDown and convenience functions.

+ +

TODO: get pydoc generated up to qpid wiki or website automatically?

+ +

Running the tests

+ +

Simplest way to run the tests:

+ +
    +
  • Run a broker on the default port
    • +
  • ./run_tests
    • +
+ + +

For additional options: ./run_tests --help

+ +

Expected failures

+ +

Until we complete functionality, tests may fail because the tested
+functionality is missing in the broker. To skip expected failures
+in the C++ or Java brokers:

+
+
./run_tests -I cpp_failing.txt
+ ./run_tests -I java_failing.txt
+
+

If you fix a failure, please remove it from the corresponding list.

+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid 'C++' Documentation.html b/documentation/content/xdocs/Qpid 'C++' Documentation.html new file mode 100755 index 0000000000..a95a97dfc7 --- /dev/null +++ b/documentation/content/xdocs/Qpid 'C++' Documentation.html @@ -0,0 +1,65 @@ + + + Apache Qpid : Qpid 'C++' Documentation + + + + + + + + + +
+
+ + Apache Qpid : Qpid 'C++' Documentation + +
+
+ This page last changed on Apr 11, 2008 by cctrieloff. +
+ +

Introduction

+ +

Contributors should read:

+ + + +

Testing guidelines:

+
    +
  • All classes should be unit tested with Boost.Test (Some tests are still using CppUnit, they will be converted.)
    • +
  • Broker should pass PythonBrokerTest with
    +
    ./run-tests -I cpp_ignore.tests
    +
    • +
+ + +

Currently built/tested with g++ on Linux using GNU make.

+ +

Design Notes

+ + + + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid .Net Documentation.html b/documentation/content/xdocs/Qpid .Net Documentation.html new file mode 100755 index 0000000000..a560b801c7 --- /dev/null +++ b/documentation/content/xdocs/Qpid .Net Documentation.html @@ -0,0 +1,68 @@ + + + Apache Qpid : Qpid .Net Documentation + + + + + + + + + +
+
+ + Apache Qpid : Qpid .Net Documentation + +
+
+ This page last changed on Aug 02, 2007 by ritchiem. +
+ +

Purpose

+ +

Introduction

+ +

Currently the .NET code base only provides a client API. You will need an AMQP broker to fully use this API.
+Qpid currently provide two broker implementations, C++ and Java.

+ +

Broker Guides

+ +

Java Broker

+ + + +

C++ Broker

+ +

User Guide

+ +

.NET User Guide

+ +

Developer Information

+ + + + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid .Net How To.html b/documentation/content/xdocs/Qpid .Net How To.html new file mode 100755 index 0000000000..24893aa85b --- /dev/null +++ b/documentation/content/xdocs/Qpid .Net How To.html @@ -0,0 +1,41 @@ + + + Apache Qpid : Qpid .Net How To + + + + + + + + + +
+
+ + Apache Qpid : Qpid .Net How To + +
+
+ This page last changed on Aug 02, 2007 by ritchiem. +
+ +

Collection of How Tos

+ + + + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Cpp Build How To.html b/documentation/content/xdocs/Qpid Cpp Build How To.html new file mode 100755 index 0000000000..6cd43ab196 --- /dev/null +++ b/documentation/content/xdocs/Qpid Cpp Build How To.html @@ -0,0 +1,80 @@ + + + Apache Qpid : Qpid Cpp Build How To + + + + + + + + + +
+
+ + Apache Qpid : Qpid Cpp Build How To + +
+
+ This page last changed on Jan 08, 2007 by aconway. +
+ +

Check out the source

+ +

Firstly, check the source for Qpid java out of our subversion repository:

+ +

https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/

+ +

Prerequisites

+ +

For the gentools need JDK 1.5 or later. You should set JAVA_HOME and include the bin directory in your PATH.

+ +

Check it's ok by executing java -v !

+ +

For build tools you need to get the correct set of tooling for Linux/ Unix or cygwin. run

+
+
./qpid-autotools-install
+
+
+ +

Build Instructions - Trunk

+ + +

Autoconf and auto build

+ +

First you need to create the gentools and initial set of files for automake and autoconf. Run:

+ +
+
./bootstrap
+
+
+

To build Qpid now run

+
+
./configure
+make 
+
+
+ +

and finally to make sure all the test pass both C++ and Pyhton run

+
+
make check
+
+
+

As a convenient shortcut you can do all of the above steps in one command with:

+
+
 ./bootstrap -build
+
+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Design - Access Control Lists.html b/documentation/content/xdocs/Qpid Design - Access Control Lists.html new file mode 100755 index 0000000000..c04d6e021c --- /dev/null +++ b/documentation/content/xdocs/Qpid Design - Access Control Lists.html @@ -0,0 +1,44 @@ + + + Apache Qpid : Qpid Design - Access Control Lists + + + + + + + + + +
+
+ + Apache Qpid : Qpid Design - Access Control Lists + +
+
+ This page last changed on Dec 06, 2007 by ritchiem. +
+ +

Overview

+ +

The AMQ Protocol specification has not yet formaly specified how access control lists should be specified or implemented as a result this is subject to change

+ +

The Java Qpid provides an authentication framework based on SASL, that provides the ability to plug in arbitrary user (or more strictly principal) databases and different SASL-compliant mechanisms. This mechanism has been extended as a proof of concept to allow access rights to a virtual host. What this page will present is an extension of this early work to include full access control across all objects in the system.

+ + +

The current access file would be modified to provide additional objects for control:

+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Design - Application Registry.html b/documentation/content/xdocs/Qpid Design - Application Registry.html new file mode 100755 index 0000000000..56cf5a2062 --- /dev/null +++ b/documentation/content/xdocs/Qpid Design - Application Registry.html @@ -0,0 +1,52 @@ + + + Apache Qpid : Qpid Design - Application Registry + + + + + + + + + +
+
+ + Apache Qpid : Qpid Design - Application Registry + +
+
+ This page last changed on Oct 19, 2006 by rgreig. +
+ +

The Application Registry is a more sophisticated version of the widely used singleton pattern. It allows the registration of services with a central component that manages the lifecycle of those services.

+ +

IApplicationRegistry

+ +

The interface IApplicationRegistry provides accessors for the following:

+ + + +

ApplicationRegistry

+ +

The abstract class ApplicationRegistry is a partial implementation of IApplicationRegistry that provides an implementation of the configured object cache as well as providing singleton access to the concrete application registry.

+ +

Subclasses should instantiate the appropriate services in order to provide access to them. Initialisation of these must be done in the initialise method so that those services can use the ApplicationRegistry themselves - attempting to initialise services in the constructor can result in NullPointerExceptions if they use the registry.

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Design - Authentication.html b/documentation/content/xdocs/Qpid Design - Authentication.html new file mode 100755 index 0000000000..da9d1b5913 --- /dev/null +++ b/documentation/content/xdocs/Qpid Design - Authentication.html @@ -0,0 +1,160 @@ + + + Apache Qpid : Qpid Design - Authentication + + + + + + + + + +
+
+ + Apache Qpid : Qpid Design - Authentication + +
+
+ This page last changed on Jun 09, 2007 by rgreig. +
+ +

Overview

+ +

The AMQ Protocol specifies that SASL is used to exchange authentication information. However, SASL on its own is only a small part of any authentication solution.

+ +

QPID provides an authentication framework based on SASL, that provides the ability to plug in arbitrary user (or more strictly principal) databases and different SASL-compliant mechanisms. This section describes how to configure both the client and broker and how to add new providers.

+ +

It is strongly recommended that any developer who needs to write a security provider or understand this in depth reads the SASL Guide that is included with the JDK documentation.

+ +

Principal Databases

+ +
Classes
+ +

Ignoring the exchange of credentials, a key thing that needs to be done is validate that the credentials are valid. The simple example is checking the username and password match those in a password file.

+ +

The interface org.apache.qpid.server.security.auth.PrincipalDatabase must be implemented by any "user database". It contains a single method, which takes the Principal and the javax.security.auth.callback.PasswordCallback that wants to receive the password. This might seem odd, since the obvious approach would be a store that took a principal and some credentials and returned a true or false indicating whether the credentials are valid. However, this approach is required to fit in with the SASL APIs which use callbacks exclusively.

+ +

The only implementation currently provided is PasswordFilePrincipalDatabase. This expects to read password from a file which is in the format username:password where the password is in plaintext and a carriage return separates each username and password pair.

+ +
Configuration
+ +

Clearly different databases will potentially require different configuration options. For example the PasswordFilePrincipalDatabase needs to be configured with the location of a password file whereas a Kerberos realm database would need to know the location of a keytab file (for example).

+ +

Configuration is specified in the configuration file like this:

+
config.xml
+
<security>
+    <principal-databases>
+        <principal-database>
+            <name>passwordfile</name>
+            <class>org.apache.qpid.server.security.auth.PasswordFilePrincipalDatabase</class>
+            <attributes>
+                <attribute>
+                    <name>passwordFile</name>
+                    <value>broker/etc/passwd</value>
+                </attribute>
+            </attributes>
+        </principal-database>
+    </principal-databases>
+</security>
+
+

After instantiating the class specified by the class element, for each attribute an attempt is made to invoke a setter method with value passed in as an argument. In the above example, the method with signature void setPasswordFile(String arg) is invoked.

+ +

The name element is significant and must be unique. The name is passed as an argument to the SASL provider implementations (described below).

+ +

Authentication Providers

+ +

The authentication process as described in the AMQ protocol specification is as follows:

+
    +
  1. Broker sends list of authentication mechanisms to the client, in order of preference
    2. +
  2. Client responds with chosen mechanism plus any initial response
    3. +
  3. Broker evaluates response and determines whether authentication has succeeded. If authentication is not yet complete, another set of challenge/responses takes place until authentication is completed (with either success or failure).
    4. +
+ + +

The broker configuration allows the administrator to configure the set of supported authentication mechanisms and the principal database used by each mechanism. It also allows the dynamic registration of additional SASL providers (this avoids the need to modify the JRE configuration).

+ +
AuthenticationProviderInitialiser
+ +

The org.apache.qpid.server.security.auth.sasl.AuthenticationProviderInitialiser interface must be implemented for each mechanism. Note this includes the SASL mechanisms that are supported by default by the JRE (e.g. CRAM-MD5). In particular, the interface allows arbitrary configuration (since each provider may have its own specialised configuration requirements), the specification of a callback handler and a factory class for JCA registration.

+ +
Configuration
+ +

The following example section from the configuration file illustrates how it might be used:

+
config.xml
+
<sasl>
+    <mechanisms>
+        <mechanism>
+            <initialiser>
+                <class>org.apache.qpid.server.security.auth.CRAMMD5Initialiser</class>
+                <principal-database>passwordfile</principal-database>
+            </initialiser>
+        </mechanism>
+        <mechanism>
+            <initialiser>
+                <class>org.apache.qpid.server.security.auth.amqplain.AmqPlainInitialiser</class>
+                <principal-database>passwordfile</principal-database>
+            </initialiser>
+        </mechanism>
+    </mechanisms>
+</sasl>
+
+

The above section defines two authentication mechanisms: CRAM-MD5 and AMQPLAIN. Since CRAM-MD5 appears first it will appear on the list of mechanisms offered to the client first. Both mechanisms are configured to use the principal database named "passwordfile" which must be defined in the appropriate section in the config file.

+ +
CallbackHandlers
+ +

Each SASL provider works with CallbackHandlers. This enables the provider to obtain information (e.g. the password) from the application as well as set the result of authentication (such as the canonical name of the principal just authenticed). The particular CallbackHandlers vary depending on the mechanism being used. The method getCallbackHandler in the AuthenticationProviderInitialiser class must return the appropriate handler for the mechanism.

+ +
AuthenticationProviderInitialiser Configuration
+ +

Since the initialisation of an authentication provider will require potentially arbitrary configuration, the interface supplies to the initialiser the Configuration object as well as the base path into the configuration file so that the initialiser can look for arbitrary configuration elements.

+ +

Client Authentication

+ +

Client authentication is similar although it is made simpler by the fact that there is no need for a PrincipalDatabase. Since we do not use any heavyweight configuration mechanism (such as the Apache Commons Configuration used by the broker) on the client side, we also need an alternative way to configure providers.

+ +
CallbackHandlerRegistry
+ +

The most important things needed on the client are:

+
    +
  1. a way to specify which SASL mechanisms we want to use, in order of preference
    2. +
  2. a way to associate a callback handler with a mechanism (remember that different mechanisms require or support different callbacks)
    3. +
+ + +

The CallbackHandlerRegistry provides a way to do this. Using a properties file to provide the configuration information, it maps from mechanisms to AMQCallbackHandler instances.

+ +

AMQCallbackHandler extends javax.security.auth.CallbackHandler and only adds one method, which associates a protocol session with a callback handler. This enables the callback handler to retrieve any specific information from the AMQProtocolSession and by extension from the javax.jms.Connection. The obvious example is the username and password.

+ +

To specify callback handlers a property file is used. The default property contains this:

+
+
CallbackHandler.CRAM-MD5=org.apache.qpid.client.security.UsernamePasswordCallbackHandler
+CallbackHandler.AMQPLAIN=org.apache.qpid.client.security.UsernamePasswordCallbackHandler
+
+

The default callbackhandler registry initialises handlers for CRAM-MD5 and AMQPLAIN. To specify your own propertyfile use the java system property amq.callbackhandler.properties.

+ +
DynamicSaslRegistrar
+ +

For SASL providers that are part of the JRE or have been added manually to the JRE security configuration all that is required is the creation of an AMQCallbackHandler. However, if you need to use a custom SASL provider it needs to be registered with JCA. Rather than place the burden for doing this on the application developer, we provide a DynamicSaslRegistrar which does this.

+ +

To configure Sasl providers, you need to create a properties file in this format:

+
+
AMQPLAIN=org.apache.qpid.client.security.amqplain.AmqPlainSaslClientFactory
+
+

The key is the mechanism name and the value is the Sasl client factory (which must implement javax.security.sasl.SaslClientFactory).

+ +

The default properties file registers only the AMQPLAIN mechanism; you can specify a custom property file using the system property amq.dynamicsaslregistrar.properties.

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Design - Configuration.html b/documentation/content/xdocs/Qpid Design - Configuration.html new file mode 100755 index 0000000000..34c2b38f25 --- /dev/null +++ b/documentation/content/xdocs/Qpid Design - Configuration.html @@ -0,0 +1,166 @@ + + + Apache Qpid : Qpid Design - Configuration + + + + + + + + + +
+
+ + Apache Qpid : Qpid Design - Configuration + +
+
+ This page last changed on Oct 19, 2006 by rgreig. +
+ +

Configuration Methods

+ +

QPID supports two methods of configuration:

+
    +
  1. command line switches (e.g. passing a -p flag on startup to specify the port)
    2. +
  2. configuration file
    3. +
+ + +

It is intended that the configuration file will be used for nearly all configuration but that some very common or useful options are exposed using command line switches.

+ +

CLI

+ +

QPID uses Commons CLI to parse command line arguments. It provides the following features:

+
    +
  • Ability to parse both short and long flags (e.g. -p and --port) and treat them as the same logical option
    • +
  • Generation of well formatted usage messages
    • +
  • Ability to specify configuration options in different ways, such as from files or from system properties, which can help when writing unit tests
    • +
+ + +

The result of parsing options, however they are specified, is a CommandLine object which can then be queried to find out specific values. Currently this is done in org.openamq.broker.Main and the CommandLine object is not exposed elsewhere but if it does require to be more widely used it could be added to the ApplicationRegistry. However it is strongly recommended that the configuration approach in the follow section is used where possible.

+ +

Configuration File

+ +

QPID uses Commons Configuration to handle nearly all configuration. It provides methods that allow parsing of options from a range of sources, including configuration files, system properties or simply hard coded classes of values (which is very useful in unit test cases).

+ +

The file format used by QPID is XML, and Commons Configuration allows a very simple XPath-like syntax to query individual elements from the configuration file.

+ +

In order to make using configuration as non-intrusive, flexible and strongly-typed as possible we do the following:

+
    +
  • Create classes representing configuration options for a particular component. For example, we have an object to represent all the connection (transport) configuration options. That object is used by the transport-related code rather than dealing with the Commons Configuration objects directly. As well as being strongly typed and easily used in unit tests, this means that a developer can see all the configuration options related to a particular feature in one place.
    • +
  • To make it easier to map between elements in the configuration file and fields in the configuration objects, a Configurable annotation (Java 5 annotation) is applied to the fields in the configuration object which contains the path expression in the configuration file, and default values should no value be specified
    • +
  • The configuration objects are stored in the ApplicationRegistry
    • +
  • The commons configuration object is stored in the ApplicationRegistry allowing "direct access" to the raw options should this be required
    • +
+ + +

Example

+ +

An example should make this clearer. Consider a (fictional) configuration file containing the following XM

+
+
<qpid>
+  <connector>
+    <ssl>true</ssl>
+    <port>5672</port>
+  </connector>
+</qpid>
+
+

To use this in the application we would define a class to represent it:

+
+
public class ConnectionConfig
+{
+    public static final String SSL_PORT = "8672";
+
+    @Configured(path = "connector.port",
+                defaultValue = DEFAULT_PORT)
+    public int port;
+
+    @Configured(path = "connector.ssl",
+                defaultValue = "false")
+    public boolean enableSSL;
+}
+
+

Note the use of @Configured to define the mapping between the configuration file and the field values.

+ +

All we need to do the access this configuration object anywhere within the application is call:

+
+
ConnectionConfig cfg = ApplicationRegistry.getInstance().getConfiguredObject(ConnectionConfig.class);
+
+

The ApplicationRegistry is documented elsewhere but from the configuration perspective all you need to know is that the first time getConfiguredObject is called for a particular class, the configuration file is parsed and the configuration object is stored for future use. Subsequent calls to getConfiguredObject for the same class are very cheap since only a hash table lookup is done.

+ +

Command Line Options

+ +

The following options are available:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
OptionLong OptionDescription
bbindBind to the specified address overriding any value in the config file
cconfigUse the given configuration file
hhelpPrints list of options
llogconfigUse the specified log4j.xml file rather than that in the etc directory
pportSpecify port to listen on. Overrides value in config file
vversionPrint version information and exit
wlogwatchSpecify interval for checking for logging config changes. Zero means no checking
+ +

Logging

+ +

Logging is handled slightly differently. The main reason for this is that logging is something we want configured before the main configuration file is processed.

+ +

The broker uses log4j as the logging implementation, and configuration must be done using the more expressive XML format. A couple of command line switches are used to configure logging:

+
    +
  • -l, --logconfig specifies the log configuration file to use. By default it looks for a file called log4j.xml located in the same directory as the config.xml file
    • +
  • -w, --logwatch the interval in seconds to poll the log configuration file for changes. The default is 60 seconds and zero means do not poll for changes.
    • +
+ + +

By using the logwatch option it is possible to make changes to the logging configuration at runtime without restarting the broker. (For example, enabling more logging on certain packages in order to diagnose a problem).

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Design - Framing.html b/documentation/content/xdocs/Qpid Design - Framing.html new file mode 100644 index 0000000000..41a3250f13 --- /dev/null +++ b/documentation/content/xdocs/Qpid Design - Framing.html @@ -0,0 +1,75 @@ + + + Apache Qpid : Qpid Design - Framing + + + + + + + + + +
+
+ + Apache Qpid : Qpid Design - Framing + +
+
+ This page last changed on Oct 19, 2006 by rgreig. +
+ +

Frame Classes

+ +

The framing definition in the protocol specification maps quite nicely to an object-oriented representation. The class diagram is shown below:

+ +

+ +

The AMQDataBlock at the root of the hierarchy defines a writePayload method that subclasses implement in order to be able to transform themselves into bytes. This is called by the encoder, documented below. The decoding (from bytes into objects) is slightly more complex since it involves factories for the instantiation of the correct objects (again documented below).

+ +

An AMQFrame is the basic unit transmitted over the network, and contains a body which is the real payload. There are numerous method frames, which are subclasses of AMQMethodBody. The method body subclasses are all code generated using XSLT from the protocol specification. The ContentHeaderBody can support different types of content properties or metadata (examples being file or stream in addition to basic which is standard JMS-style messaging).

+ +

ContentBody is a lightweight wrapper for message data.

+ +

Encoding

+ +

Encoding is a straightforward process. The AMQDataBlock class has only two method: getSize() and writePayloadToBuffer(ByteBuffer). The encoder simply needs to ask the data block its size, allocate a buffer of that size, then ask the data block to write itself into the buffer.

+ +

Decoding

+ +

The classes involved in decoding are illustrated in this UML class diagram:

+ +

+ +

The AMQDataBlockDecoder has only two methods: decodable() in which it attempts to read enough information from the supplied buffer to determine whether it has all the data and whether it appears to represent a known data block. If it needs more data, it return false. If the frame appears to be invalid it throws an exception.

+ +

The decoder stores the factories for the known frame types in a hash table, keyed on type. Assuming the decodable() method return true, the decoder constructs an AMQFrame, looks up the body factory based on the body type read from the buffer and calls populateFromBuffer on the frame, passing in the factory. The result of that call is either a fully populated frame or an exception being thrown if data is invalid or inconsistent.

+ +

The MethodBodyDecoderRegistry is generated from the ASL version of the protocol specification. (ASL is simply an XML format for describing the protocol). Each method is registered by protocol class and protocol method and when looked up by the AMQMethodBodyFactory an instance of the appropriate method body is returned. The generated code for the methods handles the reading and writing of the bytes to and from ByteBuffers as well as calculation of the size of the populated method bodies.

+ +
+
+ Attachments: +
+ +
+ + FramingClassDiagram.gif (image/gif) +
+ + DecodingClasses.gif (image/gif) +
+
+ +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Design - Framing_attachments/DecodingClasses.gif b/documentation/content/xdocs/Qpid Design - Framing_attachments/DecodingClasses.gif new file mode 100755 index 0000000000..733e9885ff Binary files /dev/null and b/documentation/content/xdocs/Qpid Design - Framing_attachments/DecodingClasses.gif differ diff --git a/documentation/content/xdocs/Qpid Design - Framing_attachments/FramingClassDiagram.gif b/documentation/content/xdocs/Qpid Design - Framing_attachments/FramingClassDiagram.gif new file mode 100755 index 0000000000..d22c8ffd09 Binary files /dev/null and b/documentation/content/xdocs/Qpid Design - Framing_attachments/FramingClassDiagram.gif differ diff --git a/documentation/content/xdocs/Qpid Design - Management.html b/documentation/content/xdocs/Qpid Design - Management.html new file mode 100755 index 0000000000..9e29793cd2 --- /dev/null +++ b/documentation/content/xdocs/Qpid Design - Management.html @@ -0,0 +1,45 @@ + + + Apache Qpid : Qpid Design - Management + + + + + + + + + +
+
+ + Apache Qpid : Qpid Design - Management + +
+
+ This page last changed on Oct 19, 2006 by rgreig. +
+ +

This page is a placeholder for more detailed information.

+ +

JVM flags

+ +

The following system properties need to be set to enable connection to the platform MBean server on the JVM running the broker:

+
+

-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8999 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

+
+ +

This obviously isn't secure but is a useful way just to get it up and running in development.

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Design - Message Acknowledgement.html b/documentation/content/xdocs/Qpid Design - Message Acknowledgement.html new file mode 100755 index 0000000000..027cdf3452 --- /dev/null +++ b/documentation/content/xdocs/Qpid Design - Message Acknowledgement.html @@ -0,0 +1,118 @@ + + + Apache Qpid : Qpid Design - Message Acknowledgement + + + + + + + + + +
+
+ + Apache Qpid : Qpid Design - Message Acknowledgement + +
+
+ This page last changed on Dec 01, 2006 by mmccorma. +
+ +

This page is under review for accuracy

+ +

Message Acknowledgements and Delivery Modes

+ +

When implementing the JMS client it became apparent that the JMS specification offered a considerable degree of latitude for interpreting the precise semantics of acknowledgement modes and it also did not cover all acknowledgement modes that are of interest.

+ +

Here we describe the precise semantics of the JMS acknowledgement modes and the additional modes that the JMS client provides.

+ +

In this discussion, "the client" refers to the JMS client implementation and "the user" refers to code that is part of the client application (i.e. code written by the end-user developer).

+ +

AUTO_ACKNOWLEDGE (JMS)

+ +

In this mode, the client acknowledges each message once it has been received by the user. In the case of an asynchronous message consumer, this means that an acknowledgement is sent once the onMessage method of a message listener has completed without throwing an exception of any sort. For a synchronous consumer, it means when the receive() method has returned the message to the user.

+ +

In this mode, each HANDLE NOTIFY sent from the server to the client will result in one CHANNEL ACK being sent from the client to the server.

+ +

CLIENT_ACKNOWLEDGE (JMS)

+ +

In this mode, the user acknowledges messages manually by calling the acknowledge() method. The user does not have to acknowledge each message therefore the user can decide on a batching strategy in order to reduce network traffic.

+ +

The JMS does not say how many message a client is allowed to receive before acknowledging. However, it does talk in vague terms about implementations making sure clients don't go too long without acknowledging to avoid resource exhaustion.

+ +

Qpid introduces a "prefetch" which specifies, for a particular destination, how many messages the client can read without sending an acknowldgement. The method Session.setDefaultPrefetch(int) allows a default value to be configured at the session level and an overloaded createConsumer() method exists allowing it to be specified at the point of consumer construction.

+ +

Calling Message.acknowledge() sends a CHANNEL ACK to be sent from the client to the server. This acknowledges the receipt of all messages up to and including this one.

+ +

DUPS_OK_ACKNOWLEDGE (JMS)

+ +

In this mode, the client acknowledges message receipt as in the case of AUTO_ACKNOWLEDGE but is not obliged to acknowledge each message immediately upon successful completion of the onMessage() or receive() methods.

+ +

This means that the client can have an "acknowledgement strategy" that can provide higher performance at the expense of potential redelivery of messages in the event of a failure.

+ +

Qpid provides a default configurable strategy parameterised on number of messages received and elapsed time since last acknowledgement. The user can configure the client to send acknowledgements every n messages (where n <= the prefetch value for the consumer) or every k milliseconds whichever is reached sooner. Values of zero for either n or k means that component of the trigger is disabled. Setting n = 0 and k = 0 results in behaviour identical to CLIENT_ACKNOWLEDGE. Setting n = 1 and k = 0 results in behaviour identical to AUTO_ACKNOWLEDGE.

+ +

PRE_ACKNOWLEDGE (non-JMS)

+ +

A mode not covered by the JMS specification is one where the client acknowledges a message before calling the onMessage() or receive() methods. This method results in the server receiving one CHANNEL ACK per HANDLE NOTIFY as in AUTO_ACKNOWLEDGE but the difference is that the ack will/can(? - this choice could cause a 'DUP' effect) be sent even if user code can throws an error.

+ +

This is useful where the user does not want to trigger redelivery of a message if user code fails or where synchronous operation is used and it is expected that there is some delay before receive() is called (which would in turn cause the server to have to wait some time before receiving the ack).

+ +

The constant Session.PRE_ACKNOWLEDGE defines this mode.

+ +

NO_ACKNOWLEDGE (non-JMS)

+ +

Certain data may be time sensitive in the sense that redelivery is pointless - if the client cannot process it at the instant it is sent there is no point in redelivering it.

+ +

In this case, acks are redundant. Since TCP means that the server can be sure the client received the message the only problem could be client error.

+ +

Setting NO_ACKNOWLEDGE means that the client never needs to send CHANNEL_ACK messages. The constant Session.NO_ACKNOWLEDGE defines this mode.

+ +

Delivery Modes

+ +

For message production, similar considerations apply. JMS defines two delivery modes, PERSISTENT and NON_PERSISTENT which allow the implmentor considerable freedom of implementation.

+ +

Unfortunately the JMS specification addresses what are really two separate reliability concerns with a single delivery mode. OpenAMQ adds an additional mode to give the user the ability to have finer control over the tradeoff between performance and reliability.

+ +

The default delivery mode can be set on a producer. This can be overridden on each message sent.

+ +

PERSISTENT (JMS)

+ +

Persistent is the straightforward option. Messages are sent with the persistent flag set to true which means that they will be committed to stable storage. HANDLE SEND frames are sent with the confirm tag set to true. When the client receives the HANDLE REPLY frame it knows that the message has been committed to stable storage on the broker.

+ +

We need to clarify with Pieter what confirm tags really mean. Do they mean pure physical receipt of the message or receipt & completion of all necessary processing? The semantics of 'processing' will vary from message-type to message-type. For example would 'HANDLE SEND' mean delivery to all end points (clients)... unlikely... or delivery to all the data-structures - queues, topics etc, or just delivery to the mux?

+ +

In this particular case 'processing' would probably mean writing to some persistent storage. Whatever the 'rule', it should be unambiguous, understood by all developers and enforced. Perhaps a 'processed' flag could be associated with the tag to indicate that it should only be generated when processing has also completed? Alternatively this could be a field that can optionally piggy-back in the confirm tag indicating that the confirm tag is also acknowledgement of completion of all necessary processing. If it does not contain that flag, then a separate acknowledgement message may be generated some time later. This gives the broker some implementation freedom.

+ +

The MessageProducer.send() method blocks until the HANDLE REPLY has been received therefore the user can know that a message has been reliably sent to the broker.

+ +

NON_PERSISTENT (JMS)

+ +

Non persistent gives maximum performance with least guarantees. The persistent flag is set to false in each message which means that if the broker dies all messages that have no been delivered at that point are lost irretrievably.

+ +

Also no acks are requested in the HANDLE SEND. Acks are pointless in this case since after sending the ack the server could die and the message would be lost.

+ +

PERSISTENT_GROUPACK (non-JMS)

+ +

An ack means that the client knows that the last message it sent was received successfully. However, acks have a considerable performance overhead. A client may want to be able to send message quickly but also have the guarantee that if the broker dies the messages will not be lost.

+ +

PERSISTENT_GROUPACK means that messages are written to stable storage, which incurs an overhead, but the client only requests an ack every n messages. The Session.setGroupAckThreshold() method allows the client to specify the ack frequency.

+ +

Note that this is different to a transacted commit since in this mode, messages can be delivered to client before the group-ack. Transacted messages are not available to clients until the commit.

+ +

TODO: define some API to allow the client to determine the set of mesages not acked in the event of failure.

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Design - Threading.html b/documentation/content/xdocs/Qpid Design - Threading.html new file mode 100755 index 0000000000..c52adc2e46 --- /dev/null +++ b/documentation/content/xdocs/Qpid Design - Threading.html @@ -0,0 +1,74 @@ + + + Apache Qpid : Qpid Design - Threading + + + + + + + + + +
+
+ + Apache Qpid : Qpid Design - Threading + +
+
+ This page last changed on Oct 19, 2006 by rgreig. +
+ +

The following diagram shows the threading model used in QPID:

+ +

+ +

Sessions

+ +

A session is the encapsulation of a client connection. A session has independent state associated with it.

+ +

Event Queues

+ +

The thread pool cannot simply be a generic pool that takes arbitrary work to process. Doing so would mean that no guarantees could be made for message ordering.

+ +

Each session has a single read event queue and it is populated by the single socket IO processor associated with the session. (Several sessions can be bound to a single IO processor; the standard select/poll mechanism is used to check for activity). Only one worker (event processing) thread can be processing the event queue for a given session but the particular thread can change over time. If more events come in while the queue is being processed, they are added to the queue being processed, and the worker thread only processes up to n events for fairness.

+ +

Similarly, for write events there is a separate queue that behaves analogously to the read queue.

+ +

One of the main benefits of this approach is that it allows enough parallelism while avoiding excessive context switching. The socket I/O processor reads as much data as it can - it does very little apart from polls and reads (side note: this makes it very straightforward to move to AIO if support is available). Message decoding (i.e. going from raw bytes to objects) and routing occurs in a worker thread but the entire dispatch process - including encoding but excluding the socket I/O - occurs on a separate worker thread. This means that on a suitable SMP box the following activities can all take place in parallel:

+
    +
  • network reading and writing for a given session
    • +
  • data decoding and routing
    • +
  • response encoding
    • +
+ + +

A further improvement would be to allow reading and writing in parallel by splitting that into separate IO processor threads, and this is being investigated (along with AIO).

+ +

Message Delivery

+ +

Messages delivered to an AMQQueue are delivered directly if possible (i.e. a write request is written to the consumers session by the thread processing the publish request). This reduces context switch or the overhead of adding and removing messages to a queue. However if there are no consumers then the message needs to be queued. In this case delivery will be done by a 'message pump' thread and direct delivery has to be stopped until the backlog of messages is processed in order to ensure that the ordering is not violated.

+ +
+
+ Attachments: +
+ +
+ + QpidThreadingModel.gif (image/gif) +
+
+ +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Design - Threading_attachments/QpidThreadingModel.gif b/documentation/content/xdocs/Qpid Design - Threading_attachments/QpidThreadingModel.gif new file mode 100755 index 0000000000..6894647a2a Binary files /dev/null and b/documentation/content/xdocs/Qpid Design - Threading_attachments/QpidThreadingModel.gif differ diff --git a/documentation/content/xdocs/Qpid Developer Documentation.html b/documentation/content/xdocs/Qpid Developer Documentation.html new file mode 100755 index 0000000000..3e7d98baa4 --- /dev/null +++ b/documentation/content/xdocs/Qpid Developer Documentation.html @@ -0,0 +1,38 @@ + + + Apache Qpid : Qpid Developer Documentation + + + + + + + + + +
+
+ + Apache Qpid : Qpid Developer Documentation + +
+
+ This page last changed on Oct 19, 2006 by rgreig. +
+ +

The child pages contain design notes on the broker and client.

+ + + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid IBM JMS Performance Test Results.html b/documentation/content/xdocs/Qpid IBM JMS Performance Test Results.html new file mode 100755 index 0000000000..22e9a1abc4 --- /dev/null +++ b/documentation/content/xdocs/Qpid IBM JMS Performance Test Results.html @@ -0,0 +1,129 @@ + + + Apache Qpid : Qpid IBM JMS Performance Test Results + + + + + + + + + +
+
+ + Apache Qpid : Qpid IBM JMS Performance Test Results + +
+
+ This page last changed on Oct 13, 2006 by mmccorma. +
+ +

Qpid IBM JMS Performance Test Results

+ +

This page is a summary of the results shown from the IBM JMS performance harness.

+ +

This page is limited to qpid-commiters.

+ +

There are few things that you should bare in mind when looking at these values.

+ +
    +
  1. The messages are 100bytes.
    2. +
  2. The Java Broker was used for the tests.
    3. +
  3. The Broker is run on an 8-way opteron (32G Total RAM) during the tests there were other process in action. +
    +
    qpid-server -c <config file to specify type of store>
    +
    4. +
  4. The Client is run on a 4 way opteron (16G Total RAM) +
    +
    qpid-run JMSPerfHarness -pc JNDI -ii com.sun.jndi.fscontext.RefFSContextFactory -iu file:///tmp/IBMPerfTestsJNDI/ -cf amq.ConnectionFactory.5670  -d amq.Queue  -tc jms.r11.PutGet -nt 6 -rl 60
    +
    5. +
  5. The two boxes are linked via private Gigabit ethernet.
    6. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
RevisionTestOptionsAverage Throughput(msgs/sec)
v452339IBM-PutGet.sh 5289.80
v452533IBM-PutGet.sh 5414.87
v462764IBM-PutGet.sh 14911.41
v452339IBM-PutGet.sh-tx2708.56
v452533IBM-PutGet.sh-tx3016.97
v462764IBM-PutGet.sh-tx3084.16
+ +

Otions: -tx = Transactional

+ +

Note: There are no values for persistent messages as the MemoryMessageStore is not persistent.

+ + +

What do the tests do.

+ +

It is worth explaining what each of the tests do so the reader can put the results in context.

+ +

The results shown above are the

+ +

IBM-PutGet.sh

+ +

The following pseudo code describes the main work of this test. There are additional timing threads and statistic threads that calculate the message throughout.

+ +
PutGet pseudo code
+
send Message
+if(using_transactions)
+    commit()
+receive Message
+if(using_transactions)
+    commit()
+
+ + + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Java Build How To.html b/documentation/content/xdocs/Qpid Java Build How To.html new file mode 100755 index 0000000000..d56c62af30 --- /dev/null +++ b/documentation/content/xdocs/Qpid Java Build How To.html @@ -0,0 +1,318 @@ + + + Apache Qpid : Qpid Java Build How To + + + + + + + + + +
+
+ + Apache Qpid : Qpid Java Build How To + +
+
+ This page last changed on Oct 25, 2007 by rgreig. +
+ +

Build Instructions - General

+ +

Check out the source

+ +

Firstly, check the source for Qpid java out of our subversion repository:

+ +

https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/java

+ +

You will also need to checkout the gentools directory at the same level:

+ +

https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/gentools

+ +

and python:

+ +

https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/python

+ +

and finally the protocol specification:

+ +

https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/specs

+ +

Prerequisites

+ +

For the broker code you need JDK 1.5 or later. You should set JAVA_HOME and include the bin directory in your PATH.

+ +

Check it's ok by executing java -v !

+ +

If you are wanting to run the python tests against the broker you will of course need a version of python.

+ + +

Build Instructions - Trunk (M2+)

+ +

Maven Build System

+ +

Useful Maven links

+ + + + + + + + + + + +

Install Maven 2

+

Firstly, you need to install Maven 2 from here).

+ +

You can find out how to set Maven up by following their quick guide.

+ +

Some of the relevant Maven targets (in Maven speak 'lifecycle phases') are as follows:

+ + + + + + + + + + + + + + + + + + + + + + +
PhaseDescription
compilecompile the source code of the project
testtest the compiled source code using a suitable unit testing framework
installcompiles & installs the package into the local repository & generates JAR files
cleancleans up artifacts created by prior builds
+ +

You can run the install phase but skip the tests by running:

+ +
+
mvn -Pfastinstall
+
+
+ +

to specify the fastinstall profile.

+ +

You can just skip the python broker tests by adding this -D option. This is done when using the fastinstall profile above.

+
+
-Dskip.python.tests
+
+
+ + +

NOTE When running under cygwin on windows the version of python that runs can give the following error "c:\windows\system32\ntvdm.exe Error while setting up environment for the application. Chose 'close' to terminate the application."
+This is due to the windows python being picked up rather than the cygwin version. When run from a cmd.exe window everything should work. If you wish to run it from a cygwin window the following option should be added to your mvn command line.

+ +
+
-Dcommand="bash -c 'python run-tests -v -I java_failing.txt'"
+
+
+ +

You can now also run the install phase with retrotranslator (for building the Java client in JDK 1.4) running:

+ +
+
mvn -Pretrotranslator
+
+
+ +

Build Qpid Java

+ +

To compile & install Qpid, cd into the java directory of your checkout and then:

+ +
+
mvn clean
+mvn install
+
+
+ +

If you wish to build an archive of Qpid for installing somewhere then:

+ +
+
cd distribution
+mvn
+
+
+ +

NB: executing Maven in the distribution directory does NOT force a clean build or a re-JAR, but uses the jars from your repository. You must be sure to execute a clean install in the java directory first (up one level from the distribution directory) to get a clean distribution. Best to check that the jars in your repository are current before building a dist!

+ +

Build/Debug Cycle

+ +

If you're changing code as part of a debugging effort and want to quickly rebuild and then run the broker for manual testing, you can use the following commands, starting in the top-level java directory:

+ +
+
mvn -Pfastinstall
+cd distribution
+mvn assembly:directory
+
+
+ +

The first command above builds everything but skips the tests. The last command above builds the normal distribution but also creates a directory holding the contents of the Java bin assembly. You can run the broker directly from that directory by setting QPID_HOME to point to it. For example, for the Qpid incubating 1.0 M2 snapshot version, the assembly directory resulting from running the final command above is:

+ +
+
target/qpid-1.0-incubating-M2-SNAPSHOT-java-bin
+
+
+ +

If you set the QPID_HOME environment variable to the directory contained within the directory named above, i.e.:

+ +
+
target/qpid-1.0-incubating-M2-SNAPSHOT-java-bin/qpid-1.0-incubating-M2-SNAPSHOT
+
+
+ +

and add $QPID_HOME/bin (UNIX) or %QPID_HOME%\bin (Windows) to your PATH, you can then run the broker by executing the qpid-server script.

+ +

You can also control where the assembly directory is built via the qpid.targetDir property, like this:

+ +
+
mvn -Dqpid.targetDir=/tmp/xyz assembly:directory
+
+
+ +

This will create the assembly directory and the various tar and zip files in directory /tmp/xyz.

+ +

In summary, with QPID_HOME set as described above, the edit/build/debug cycle becomes a matter of first rebuilding the appropriate artifacts, either from the top level or within the specific subdirectory for a single modified artifact, changing to the distribution directory, and creating the assembly directory as described above. You can then run the broker via qpid-server and perform your debugging, testing, etc.

+ +

Building Project Files

+ +

You can build project files for IntelliJ IDEA and Eclipse IDEs by executing the appropriate command in the java directory:

+ + + + + + + + + + + + + + +
CommandResult
mvn idea:ideaBuilds .ipr and .iml files with appropriate project settings for classpath etc
mvn eclipse:eclipseBuilds Eclipse project files with settings
+ +

To get started with Eclipse, use the setup.eclipse profile:

+ +
+
mvn -Psetup.eclipse
+
+
+ +

The setup.eclipse profile will by default create an Eclipse workspace in the ../workspace directory. You then go into Eclipse, switch to the new workspace, and then import the Qpid projects by selecting File -> Import -> Existing projects into workspace.

+ +

If you want to set up a workspace other than ../workspace, you can specify it on the command line via the eclipse.workspace.dir property:

+ +
+
mvn -Declipse.workspace.dir=/path/to/workspace -Psetup.eclipse
+
+
+ +

Build Instructions - M1 branch

+ +

Ant Build Scripts

+ +

Currently the Qpid java project builds using ant.

+ +

The ant build system is set up in a modular way, with a top level build script and template for module builds and then a module level build script which inherits from the template.

+ +

So, at the top level there are:

+ + + + + + + + + + + + + + + + + + +
FileDescription
build.xmlTop level build file for the project which defines all the build targets
common.xmlCommon properties used throughout the build system
module.xmlTemplate used by all modules which sets up properties for module builds
+ +

Then, in each module subdirectory there is:

+ + + + + + + + + + +
FileDescription
build-module.xmlDefines all the module values for template properties
+ +

Build targets

+ +

The main build targets you are probably interested in are:

+ + + + + + + + + + + + + + +
TargetDescription
buildBuilds all source code for Qpid java
archiveGenerates all distribution archives for Qpid java
+ +

So, if you just want to compile everything you should run the build target in the top level build.xml file.

+ +

If you want to build an installable version of Qpid java, run the archive task from the top level build.xml file.

+ +

If you want to compile an individual module, simply run the build target from the appropriate build-module.xml e.g. to compile the broker source, simply run the build target in the java/broker/build-module.xml file.

+ +

What next ?

+ +

If you want to run your built Qpid package, see our Getting Started Guide for details of how to do that.

+ +

If you want to run our tests, you can use the ant test or testreport (produces a useful report) targets.

+ +
+
+ Attachments: +
+ +
+ + mavenlinks.html (text/html) +
+
+ +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Java Build How To_attachments/mavenlinks.html b/documentation/content/xdocs/Qpid Java Build How To_attachments/mavenlinks.html new file mode 100755 index 0000000000..d0b92fafec --- /dev/null +++ b/documentation/content/xdocs/Qpid Java Build How To_attachments/mavenlinks.html @@ -0,0 +1,11 @@ + + + + + + + + + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Java Client refactoring.html b/documentation/content/xdocs/Qpid Java Client refactoring.html new file mode 100755 index 0000000000..1e23dbfa4a --- /dev/null +++ b/documentation/content/xdocs/Qpid Java Client refactoring.html @@ -0,0 +1,59 @@ + + + Apache Qpid : Qpid Java Client refactoring + + + + + + + + + +
+
+ + Apache Qpid : Qpid Java Client refactoring + +
+
+ This page last changed on Apr 02, 2007 by ritchiem. +
+ +

Summary
+---------
+The goals of the re-factoring are as follows.

+ +

1. Provide an AMQP protocol level API.
+2. Achieve a clear separation of concerns.
+3. Implement proper state and event handling.
+4. Provide extensibility to extend the API at any level.
+5. Provide a unified interface for configuration through jvm
+arguments,xml ..etc. (Used commons configuration)

+ +

The Prototype is available here https://svn.apache.org/repos/asf/incubator/qpid/branches/client_restructure/java/newclient/

+ +

The following document describes the design. java_amqp_client_design.pdf

+ +
+
+ Attachments: +
+ +
+ + java_amqp_client_design.pdf (application/pdf) +
+
+ +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Java Client refactoring_attachments/java_amqp_client_design.pdf b/documentation/content/xdocs/Qpid Java Client refactoring_attachments/java_amqp_client_design.pdf new file mode 100755 index 0000000000..bbe7e4b276 Binary files /dev/null and b/documentation/content/xdocs/Qpid Java Client refactoring_attachments/java_amqp_client_design.pdf differ diff --git a/documentation/content/xdocs/Qpid Java Documentation.html b/documentation/content/xdocs/Qpid Java Documentation.html new file mode 100755 index 0000000000..9fc55b8fd8 --- /dev/null +++ b/documentation/content/xdocs/Qpid Java Documentation.html @@ -0,0 +1,108 @@ + + + Apache Qpid : Qpid Java Documentation + + + + + + + + + +
+
+ + Apache Qpid : Qpid Java Documentation + +
+
+ This page last changed on Oct 25, 2007 by cctrieloff. +
+ +

Purpose

+ +

This is the index of all Qpid Java Documentation.

+ +

Introduction

+ +

The Qpid pure Java broker currently supports the following features:

+ +
    +
  • All features required by the Sun JMS 1.1 specification
    • +
  • Transaction support
    • +
  • Persistence using a pluggable layer
    • +
  • Pluggable security using SASL. Any Java SASL provider should be capable of working with Qpid.
    • +
  • Management using JMX and an Eclipse RCP application
    • +
  • Clustering for scalability
    • +
  • High performance header-based routing for messages
    • +
+ + +

Useful Links

+ +

General User Guides

+ + + + +

Management Tools

+ + + + +

Developer Information

+ + + + +

Testing

+ +

Interoperability Testing

+ +

Performance Testing

+ + + + +

Release Plans

+ + + + + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Java FAQ.html b/documentation/content/xdocs/Qpid Java FAQ.html new file mode 100755 index 0000000000..36cc135152 --- /dev/null +++ b/documentation/content/xdocs/Qpid Java FAQ.html @@ -0,0 +1,330 @@ + + + Apache Qpid : Qpid Java FAQ + + + + + + + + + +
+
+ + Apache Qpid : Qpid Java FAQ + +
+
+ This page last changed on Mar 10, 2008 by ritchiem. +
+ + + +

What is Qpid ?

+
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Java FAQ_attachments/appContext.zip b/documentation/content/xdocs/Qpid Java FAQ_attachments/appContext.zip new file mode 100755 index 0000000000..ab97d5f1f5 Binary files /dev/null and b/documentation/content/xdocs/Qpid Java FAQ_attachments/appContext.zip differ diff --git a/documentation/content/xdocs/Qpid Java How To.html b/documentation/content/xdocs/Qpid Java How To.html new file mode 100755 index 0000000000..aa141a689f --- /dev/null +++ b/documentation/content/xdocs/Qpid Java How To.html @@ -0,0 +1,41 @@ + + + Apache Qpid : Qpid Java How To + + + + + + + + + +
+
+ + Apache Qpid : Qpid Java How To + +
+
+ This page last changed on Nov 22, 2006 by ritchiem. +
+ +

Collection of How Tos

+ + + + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Java M1 Release Notes.html b/documentation/content/xdocs/Qpid Java M1 Release Notes.html new file mode 100755 index 0000000000..3437cc1194 --- /dev/null +++ b/documentation/content/xdocs/Qpid Java M1 Release Notes.html @@ -0,0 +1,66 @@ + + + Apache Qpid : Qpid Java M1 Release Notes + + + + + + + + + +
+
+ + Apache Qpid : Qpid Java M1 Release Notes + +
+
+ This page last changed on Nov 10, 2006 by mmccorma. +
+ +

This is the list of JIRA tasks completed for M1

+ +

Bugs
+QPID-4 - Remove '/' and ':' from generated queue names
+QPID-7 - Occasionally messages are ack'd more than once
+QPID-10- Broker throughput falls off with transactions
+QPID-56 - AMQQueueMBean - MessageCount on the management interface is not correct.
+QPID-58 - Creating a QueueReceiver results in ClassCastException
+QPID-66 - AMQSession implementation of TopicSession and QueueSession interfaces not JMS compliant
+QPID-68 - Ant build system fails if the project path contains a space
+QPID-69 - Race condition in Delivery Manager

+ +

Improvements
+QPID-36 - Add high and low watermark to flow control
+QPID-44 - Add high and low watermark to flow control
+QPID-57 - AMQQueueMBean - Message header attributes should be sent along with message content.

+ + +

New Features
+QPID-13 - Add option to include prefix and suffix in log file name for broker
+QPID-23 - Extend JNDI support provided to include initial context factory
+QPID-29 - Provide support for using Qpid JMX with Tivoli for application monitoring
+QPID-30 - Allow configuration of working/log directories written to by broker
+QPID-40 - Implement tx.select, tx.commit & tx.rollback from AMQP

+ + +

Tasks
+QPID-18 - Update Java client and broker to MINA 1.0 release
+QPID-73 - Create Build Artifacts for release process using ant/maven
+QPID-74 - Create source distribtuion using build system
+QPID-75 - Create Standard Binary distribution using build system

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Java Meeting Minutes 04-04-2008.html b/documentation/content/xdocs/Qpid Java Meeting Minutes 04-04-2008.html new file mode 100755 index 0000000000..fc0c5c596f --- /dev/null +++ b/documentation/content/xdocs/Qpid Java Meeting Minutes 04-04-2008.html @@ -0,0 +1,559 @@ + + + Apache Qpid : Qpid Java Meeting Minutes 04-04-2008 + + + + + + + + + +
+
+ + Apache Qpid : Qpid Java Meeting Minutes 04-04-2008 + +
+
+ This page last changed on Apr 04, 2008 by godfrer. +
+ +

Agenda

+ +
    +
  • ApacheCon Europe
    • +
  • Update on M2.1 release process
    • +
  • Review of code commits
    • +
  • Review of new JIRAs
    • +
  • Update on GSoC projects
    • +
+ + + +

Attendees

+ +

ApacheCon Europe

+ +

No-one available to travel on those dates

+ +

Update on M2.1 release process

+ +

Need to update the release notes in the release
+Taking out the .svn directories
+May cause the release to slip by a couple of days

+ +

Review of code commits

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Revision Committer Date Comment (1st line)
r642346 gsim 2008-03-28 Prefer binding key for unbind if specified.
r642375 nsantos 2008-03-28 QPID-885: patch from Ted Ross
r642959 gsim 2008-03-31 Prevent broker exit on receiving connection with invalid protocol version.
r642981 gsim 2008-03-31 Re-introduced old 'no-local' behaviour for exclusive queues via a proprietary arg to queue.declare.
r643032 ritchiem 2008-03-31 QPID-890 : Removed old references to VHostPrincipalDatabase and an errant old.PrincipalDatabaseAccessManager change.
r643067 gsim 2008-03-31 Updated xml fragment to reflect correct types for connection.start.mechanisms, connection.start.locales and connection.open.capabilities
r643086 gsim 2008-03-31 Allow zero sized arrays (with no typecode or count)
r643153 aidan 2008-03-31 Add licensces
r643154 aidan 2008-03-31 Created prematurely, will recreate from release branch
r643155 aidan 2008-03-31 Branch for M2.1 release
r643162 aidan 2008-03-31 Update version in poms Some versions are wrong in the poms, need correcting (fixed later)
r643165 aidan 2008-03-31 Tag RC1
r643442 nsantos 2008-04-01 QPID-892: Make qpidd daemon not run as root (rpm install)
r643472 gsim 2008-04-01 Fix some erroneous definitions in the transitional xml fragment for 0-10.
r643478 gsim 2008-04-01 Added a dump method to buffer for debugging io (patch from rafaels@redhat.com)
r643482 gsim 2008-04-01 Further correction to transitional xml def for final 0-10 (using old schema)
r643582 aidan 2008-04-01 Add my gpg key
r643597 nsantos 2008-04-01 QPID-892 - use daemon params instead of runuser; store pid of qpidd daemon to kill single instance
r643613 aidan 2008-04-01 Set version to M2.1 for all, it's release time
r643624 aidan 2008-04-01 Tag the first M2.1 to get voted on
r643822 arnaudsimon 2008-04-02 QPID-829 Remove 0.10 specific URL. The code path is now selected based on broker response. We first try the highest protocol version and update the handler if the broker replies with a different protocol version. NOTE that we need to update the current java broker and 0.8 client for handling protocol headers. This should happen with the M2.1 merge. For the moment we only support an in VM 0.8 broker. Moreover, we'll need to migrate to a 0.10 vs 99.0 protocol version. Question coding standards on import statements (amend to allow .* ; remove unneeded imports ) ; Should probably add ability to set explicit AMQP version
r643891 aconway 2008-04-02 Fix gcc 4.3 warnings.
r643894 arnaudsimon 2008-04-02 QPID-884 Updated ant for using a profile. I have created a default profile that runs the tests against an 0.8 in VM broker and cpp-async and cpp-sync that respectively runs the test against an 0.10 cpp broker with async store and with sync store. Update wiki documents to discuss the availble stores ; document where to put them ; make another test which refers to no store
r643900 aconway 2008-04-02 Fix doxygen warnings.
r643914 aconway 2008-04-02 Fix gcc 4.3 warnings.
r643924 arnaudsimon 2008-04-02 QPID-884 made ant task test alton/error/failure configurable from profile file
r643957 aconway 2008-04-02 Fixed logger warning on F9.
r643995 aconway 2008-04-02 Encoding/decoding for new types: amqp_0_10::Map, amqp_0_10:UnknownType
r644005 aconway 2008-04-02 Fix compile error on rhel5.
r644125 aconway 2008-04-03 Fix serialize test failure on 64 bit architerctures.
r644245 arnaudsimon 2008-04-03 QPID-897 this test was intermittently failing because of too short timeouts. This fix is a temporary measure until we agree about using a configurable receive timeout. hold off on permanent fix until after merge
r644287 kpvdr 2008-04-03 Patch from Ted Ross (see QPID-893): This patch enables management of plugged-in store modules.
r644308 aconway 2008-04-03 amqp_0_10/built_in_types.h
r644413 aconway 2008-04-03 src/qpid/amqp_0_10/Map.h,.cpp: use preview encoding temporarily.
r644461 aconway 2008-04-03 rubygen/0-10/exceptions.rb:
r644533 aconway 2008-04-03 qpid/Serializer.h, qpid/amqp_0_10/Codec.h:
r644688 arnaudsimon 2008-04-04 QPID-796: Added ability to enable/disable message prefetching. Prefetching is controlled through the property max_prefetch, it is turned off when max_prefetch =0. (this is 0.10 code path change) `Rauise JIRA for spelling mistakes in classes (e.g. BasicMessageConsumer_0_10 strated() BasicMessageConsumer, etc ; startDistpatcher ... Replace ClientProperties.MAX_PREFETCH == 0 with method e.g. disallowMessagePrefetch() ... maybe make a connection URL property
r644689 arnaudsimon 2008-04-04 QPID-798 Added boolean property fully_sync when true a sync is sent after a persistent message is transfered. Make property per connection, rather than system wide; maybe change name to SYNC_PERSISTENT to denote only used on persistent messages
+ + +

Review of new JIRAs

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
KeyComponent/sAffects Version/sSummaryStatusAssigneeReporter
QPID-902 C++ Broker, Python Client Management Improvements for C++ BrokerOpenUnassignedTed Ross
QPID-901 Java Client update the java client to the 0-10 final specOpenRafael H. SchlomingRafael H. Schloming
QPID-900 Java CommonM2.1Java Common AMQShortString should not create new byte[] backing when based off a heap bufferOpenRob GodfreyRob Godfrey
QPID-899 Java CommonM2.1Java Common Bug in AMQShortString on tokenized substringsOpenRob GodfreyRob Godfrey
QPID-898 Ant Build System remove .tar.bz2 from release targetOpenUnassignedNuno Santos
QPID-897 Java TestsM3Configurable receive timeoutOpenUnassignedArnaud Simon
QPID-896 Java Client Provide Simple Pub/Sub examples that do not use extendsOpenMartin RitchieMartin Ritchie
QPID-895   FailoverSingleServer delays on first connection.OpenUnassignedMartin Ritchie
QPID-894 Java Common Dependency on commons-lang: real need for 2.2, or can use 2.1?OpenRafael H. SchlomingNuno Santos
QPID-893 C++ Broker Enable management of plugged-in store moduleClosedUnassignedTed Ross
QPID-892 C++ Broker Make qpidd daemon not run as root (rpm install)ResolvedUnassignedNuno Santos
QPID-891 Java Broker QueueDeclare reports incorrect message count on queueOpenUnassignedMartin Ritchie
QPID-890  M2.1Broker transient_config.xml still contains reference to outdated principal database :PlainPasswordVhostFilePrincipalDatabaseResolvedMartin RitchieMartin Ritchie
QPID-889 Java BrokerM2, M2.1Requirement for _reapingStoreContext should be removed.OpenMartin RitchieMartin Ritchie
QPID-888  M2, M2.1Management methods don't correctly protect _lock from being lost on errorOpenUnassignedMartin Ritchie
QPID-887 Java BrokerM2, M2.1QueueHousekeeping threads are poorly namedOpenUnassignedMartin Ritchie
QPID-886 Java BrokerM2, M2.1CSDM.removeExpired() doesn't relinquish lock causing broker hang.OpenMartin RitchieMartin Ritchie
QPID-885 Python Client Broker configuration utilityClosedUnassignedTed Ross
QPID-884 Java TestsM3Improve ant task test configurationClosedArnaud SimonArnaud Simon
QPID-883 Python Client Synchronous API in management.pyClosedUnassignedTed Ross
QPID-882 Java ClientM3XAResource does not check pre and post-conditionsOpenArnaud SimonArnaud Simon
QPID-881 Java ClientM3Commands waiting on a future are not notified of a connection closed eventOpenRafael H. SchlomingArnaud Simon
QPID-880 Java ClientM2,M2.1Client is still using broker set temporary queue namesOpenUnassignedMartin Ritchie
QPID-879 C++ Broker Adding support for XML-based routingOpenUnassignedJonathan Robie
QPID-878 Java TestsM3Some tests are not run by ant as their class name does not end by TestClosedArnaud SimonArnaud Simon
QPID-877 C++ Broker, Python Client Management protocol and API improvementsClosedUnassignedTed Ross
+ + + + +

Update on GSoC projects

+ +

Had some interest, not all have been submitted.

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Java Meeting Minutes 11-04-2008.html b/documentation/content/xdocs/Qpid Java Meeting Minutes 11-04-2008.html new file mode 100755 index 0000000000..26fc541cb9 --- /dev/null +++ b/documentation/content/xdocs/Qpid Java Meeting Minutes 11-04-2008.html @@ -0,0 +1,513 @@ + + + Apache Qpid : Qpid Java Meeting Minutes 11-04-2008 + + + + + + + + + +
+
+ + Apache Qpid : Qpid Java Meeting Minutes 11-04-2008 + +
+
+ This page last changed on Apr 11, 2008 by ritchiem. +
+ +

Agenda

+ +
    +
  • Update on M2.1 release process
    • +
  • Review of code commits
    • +
  • Review of new JIRAs
    • +
  • Update on GSoC projects
    • +
+ + +

Attendees

+ +

Rob Godfrey
+Aidan Skinner
+Marnie McCormack
+Martin Ritchie
+Carl Trieloff
+Rajith Attapatu
+Rafael Schloming
+Gordon Sim

+ +

Update on M2.1 release process

+ +

RC3 is out, release instructions need to be updated.
+C++ documentation should exist

+ +

Review of code commits

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
revision committer date comment
r644689 arnaudsimon 2008-04-04 13:11:38 +0100 (Fri, 04 Apr 2008) QPID-798 Added boolean property fully_sync when true a sync is sent after a persistent message is transfered. .
r644727 aconway 2008-04-04 15:42:36 +0100 (Fri, 04 Apr 2008) src/qpid/amqp_0_10/Assembly.cpp,.h:
r644732 nsantos 2008-04-04 15:58:01 +0100 (Fri, 04 Apr 2008) QPID-898: move bz2 generation from the release target to a new release-all target
r644806 kpvdr 2008-04-04 19:14:42 +0100 (Fri, 04 Apr 2008) Patch from Ted Ross (see QPID-902): This patch contains the following improvements for management:\n1) Schema display cleaned up in the python mgmt-cli\n2) Locking added automatically to management object accessors (manual
+ locking removed from broker/Queue.cpp)\n3) Schemas are now pre-registered with the management agent using a package initializer. This allows management consoles to get schema information for a class even if no instances of the class exist.
r644812 kpvdr 2008-04-04 19:25:08 +0100 (Fri, 04 Apr 2008) Additional files for Ted Ross's checkin
r644845 aconway 2008-04-04 20:35:14 +0100 (Fri, 04 Apr 2008) Minor cleanup of base Exception and python_tests script.
r644917 aconway 2008-04-04 22:00:40 +0100 (Fri, 04 Apr 2008) src/qpid/amqp_0_10/Exception.h
r645470 gsim 2008-04-07 12:51:07 +0100 (Mon, 07 Apr 2008) AsynchIoAcceptor.cpp: Limit output from codec to one buffer per 'idle' call.
r645593 aidan 2008-04-07 17:27:20 +0100 (Mon, 07 Apr 2008) Add toplevel NOTICE and LICENSE files, add Felix to java/resources/NOTICE, make sure all spec files are included in java source distribution
r645663 aconway 2008-04-07 21:12:31 +0100 (Mon, 07 Apr 2008) Encoding/decoding for packed structs and optional members.
r645664 aconway 2008-04-07 21:13:59 +0100 (Mon, 07 Apr 2008) Missing from last commit.
r645670 aconway 2008-04-07 21:42:28 +0100 (Mon, 07 Apr 2008) Fix rhel5 build errors.
r645685 astitcher 2008-04-07 21:59:02 +0100 (Mon, 07 Apr 2008) Fixed time classes for some changes that misunderstood how they are supposed
r645699 aconway 2008-04-07 22:16:48 +0100 (Mon, 07 Apr 2008) rubygen/0-10/specification.rb
r645731 aidan 2008-04-08 00:05:28 +0100 (Tue, 08 Apr 2008) Update release notes
r645732 aidan 2008-04-08 00:07:50 +0100 (Tue, 08 Apr 2008) Tag M2.1 RC3
r645733 aconway 2008-04-08 00:22:36 +0100 (Tue, 08 Apr 2008) src/qpid/amqp_0_10/Body.h, Header.h: placeholders.
r645804 gsim 2008-04-08 10:18:10 +0100 (Tue, 08 Apr 2008) Fixed compilation error from ignored qualifier on function return type.
r645826 gsim 2008-04-08 11:16:32 +0100 (Tue, 08 Apr 2008) Removed out-of-date and misleading comment.
r645951 gsim 2008-04-08 15:48:25 +0100 (Tue, 08 Apr 2008) QPID-903: changed read-write lock to mutex (currently recursive) to avoid deadlocking when adding bridge.
r646045 kpvdr 2008-04-08 20:29:08 +0100 (Tue, 08 Apr 2008) Patch from Ted Ross: QPID-907: Management Improvements for C++ Broker and Store
r646054 aconway 2008-04-08 20:53:07 +0100 (Tue, 08 Apr 2008) Summary: added 0-10 Array encoding and decoding.
r646071 aconway 2008-04-08 22:02:14 +0100 (Tue, 08 Apr 2008) Touched existing template so new template allSegmentTypes.rb will be noticed.
r646093 cctrieloff 2008-04-08 22:51:17 +0100 (Tue, 08 Apr 2008) QPID-908 from tross
r646099 aconway 2008-04-08 23:11:40 +0100 (Tue, 08 Apr 2008) Fix packaing problem with generated file allSegmentTypes.h
r646113 aidan 2008-04-08 23:46:06 +0100 (Tue, 08 Apr 2008) Nuke
r646114 aidan 2008-04-08 23:46:10 +0100 (Tue, 08 Apr 2008) use svnexe for uploading, generate source jars
r646115 aidan 2008-04-08 23:46:26 +0100 (Tue, 08 Apr 2008) Tag M2.1 RC3
r646376 aconway 2008-04-09 15:25:09 +0100 (Wed, 09 Apr 2008) Improved diagnostics in allSegmentTypes test.
r646452 gsim 2008-04-09 18:59:38 +0100 (Wed, 09 Apr 2008) Handle the set-redelivered flag on the final version of the message.release command.
r646505 gsim 2008-04-09 20:52:44 +0100 (Wed, 09 Apr 2008) Fixes and automated tests for federation function.
r646519 rajith 2008-04-09 21:31:28 +0100 (Wed, 09 Apr 2008) This is a fix for QPID-911. When the message id is set, _hasBeenUpdated will be set to true.
r646778 aconway 2008-04-10 13:36:58 +0100 (Thu, 10 Apr 2008) Invocation handlers, see src/tests/amqp_0_10/handlers.cpp for example.
r646783 aconway 2008-04-10 14:00:04 +0100 (Thu, 10 Apr 2008) Use "Exception" instead of typeid.name() as default exception name. Mangled type names are too confusing.
r646791 kpvdr 2008-04-10 14:17:44 +0100 (Thu, 10 Apr 2008) Minor change to format of log message when exception is thrown
r646943 aconway 2008-04-10 21:15:08 +0100 (Thu, 10 Apr 2008) amqp_0_10: Encoding for packed structs.
r647099 gsim 2008-04-11 11:02:49 +0100 (Fri, 11 Apr 2008) QPID-913: committed patch from tross@redhat.com
r647123 gsim 2008-04-11 12:44:12 +0100 (Fri, 11 Apr 2008) Set executable property for commands
+
    +
  • Attempt to achieve consensus on qpid-dev that all (C++) commits have a JIRA at the start
    • +
  • AS to fix release notes, again
    • +
  • r646519 should use updated(), check if QPID-911 affects M2.1, audit class for other usages of hasUpdated directly
    • +
+ + +

Review of new JIRAs

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Key Component/s Affects Version/s Summary Status Assignee Reporter
QPID-913 Python Client   Reorganization of python utilities + a bug fix Open Unassigned Ted Ross
QPID-912 Java Client M2,M2.1 AMQSession.getQueueDepth should better describe its failure conditions. Open Unassigned Martin Ritchie
QPID-911 Java Client M3 MessageID is not set for outgoing messages if that is the only property set Resolved Rajith Attapattu Rajith Attapattu
QPID-910 Java Broker,Java Client M2.1 Some poms reference inappropriate mvn repos Open Aidan Skinner Aidan Skinner
QPID-909 Java Tests M2.1 DurationTestDecorator doesn't work in conjunction with the ScaledTestDecorator Open Unassigned Martin Ritchie
QPID-908 Python Client   Python command utility for federation routes Closed Unassigned Ted Ross
QPID-907 C++ Broker,Python Client   Management Improvements for C++ Broker and Store Closed Unassigned Ted Ross
QPID-906 Java Client M2.1 java.lang.NumberFormatException silently ignored in MessageListener.onMessage(Message message) Open Unassigned Alasdair MacLeod
QPID-905 Java Client   org.apache.qpid.client.ClientProperties dies ungracefully when max_prefetch is not set to a valid number Open Unassigned Rafael H. Schloming
QPID-904    broker.clean is not set properly in any of the test profiles Open Unassigned Rafael H. Schloming
QPID-903 C++ Broker   Federation (inter-broker) links cause C++ broker to hang Closed Unassigned Ted Ross
QPID-902 C++ Broker,Python Client   Management Improvements for C++ Broker Closed Unassigned Ted Ross
QPID-901 Java Client   update the java client to the 0-10 final spec Open Rafael H. Schloming Rafael H. Schloming
QPID-900 Java Common M2.1 Java Common AMQShortString should not create new byte[] backing when based off a heap buffer Open Rob Godfrey Rob Godfrey
QPID-899 Java Common M2.1 Java Common Bug in AMQShortString on tokenized substrings Open Rob Godfrey Rob Godfrey
QPID-898 Ant Build System   remove .tar.bz2 from release target Resolved Unassigned Nuno Santos
QPID-897 Java Tests M3 Configurable receive timeout Open Unassigned Arnaud Simon
QPID-896 Java Client   Provide Simple Pub/Sub examples that do not use extends Open Martin Ritchie Martin Ritchie
QPID-895 Java Client   FailoverSingleServer delays on first connection. Open Unassigned Martin Ritchie
QPID-894 Java Common   "Dependency on commons-lang: real need for 2.2, or can use 2.1?" Open Rafael H. Schloming Nuno Santos
+ + +
    +
  • RS - new JIRA to moving try catch to just around onMessage()
    • +
  • RS - Take QPID-906 and check that it is JMS Spec compliant
    • +
  • CT - find cruise control files
    • +
  • CT - JIRA time tracking is broken, normalises 1d is 24h should be 8h
    • +
+ + +

Update on GSoC projects

+ +

We discusssed our project proposals

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Java Meeting Minutes 2008-04-18.html b/documentation/content/xdocs/Qpid Java Meeting Minutes 2008-04-18.html new file mode 100755 index 0000000000..022ae98dc8 --- /dev/null +++ b/documentation/content/xdocs/Qpid Java Meeting Minutes 2008-04-18.html @@ -0,0 +1,945 @@ + + + Apache Qpid : Qpid Java Meeting Minutes 2008-04-18 + + + + + + + + + +
+
+ + Apache Qpid : Qpid Java Meeting Minutes 2008-04-18 + +
+
+ This page last changed on Apr 18, 2008 by godfrer. +
+ +

Agenda

+ +
    +
  • Update on Merge
    • +
  • Update on M2.1 release process
    • +
  • Review of code commits
    • +
  • Review of new JIRAs
    • +
  • Update on GSoC projects
    • +
+ + +

Attendees

+ + +

Aidan Skinner
+Arnaud Simon
+Carl Trieloff
+Martin Ritchie
+Robert Godfrey

+ + +

Apologies

+ +

Gordon Sim

+ + + +

Update on M2.1 release process

+ + + +

Review of code commits

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Revision Committer Date Commit Comment Review Points
r647227 rhs 2008-04-11 QPID-901 : temporary workaround for AMQP-218  
r647270 kpvdr 2008-04-11 Patch from Ted Ross: added set methods to hilo types in generated management classes  
r647616 aidan 2008-04-13 QPID-916 Correct release notes  
r647620 aidan 2008-04-13 QPID-916 tag RC4  
r647704 gsim 2008-04-14 QPID-917 : Use PLAIN (rather than the non-standard AMQPLAIN) as the SASL mechanism when authenticating python test clients.  
r647710 gsim 2008-04-14 Correction to release notes (now support AMQP 0-9)  
r647716 gsim 2008-04-14 QPID-648 : Initial support for sasl authentication for c++ broker. From patch submitted by mfarrellee@redhat.com. Authentication is optional at compile time (based on user selection or availability of ...  
r647726 aidan 2008-04-14 QPID-832 delete for resync with trunk (cpp, ruby) and M2.1 (java/broker)  
r647727 aidan 2008-04-14 QPID-832 sync cpp with trunk  
r647728 aidan 2008-04-14 QPID-832 sync ruby from trunk  
r647730 aidan 2008-04-14 QPID-832 sync broker with M2.1  
r647800 gsim 2008-04-14 QPID-648 : keep the sasl_conn member in the handler to avoid the need for friend declaration  
r647825 aidan 2008-04-14 QPID-916 Tag RC5, with correct C++ release notes  
r647887 rhs 2008-04-14 fixed encode/decode of structs in command/control arguments to include the type code when specified  
r647903 gsim 2008-04-14 Use the errata file for final 0-10 that has a type code for xids without which dtx.recover can't work. Return the indoubt xids as an array of struct32s each of which contains an encoded xid.  
r647937 aconway 2008-04-14 https://bugzilla.redhat.com/show_bug.cgi?id=441080 from Ville Skyttä (ville.skytta@iki.fi) qpidc's build does not use $RPM_OPT_FLAGS so it misses some compiler security features, and strips installed ...  
r647940 gsim 2008-04-14 QPID-648 : more flexible sasl implementation (patch provided by mfarrellee@redhat.com)  
r647990 gsim 2008-04-14 Fix to struct32 encoding  
r647999 gsim 2008-04-14
    +
  • Fix interpretation of accept-mode, 0 == EXPLICIT * Ensure accepts are taken into account in command sequence
    • +
+		 
r648013 nsantos 2008-04-14 fix home dir permissions  
r648095 aconway 2008-04-15 Struct32 encoding  
r648194 gsim 2008-04-15 Remove deleted file from distribution list.  
r648196 gsim 2008-04-15 QPID-648 : Get list of supported mechanisms from sasl lib. (Patch from mfarrellee@redhat.com)  
r648207 aidan 2008-04-15 Merged revisions 631979-647797 via svnmerge from https://svn.apache.org/repos/asf/incubator/qpid/trunk ........ r631987 - aconway - 2008-02-28 14:47:59 +0000 (Thu, 28 Feb 2008) - 2 lines Fixe ...  
r648216 aidan 2008-04-15 Merged revisions 627417-648207 via svnmerge from https://svn.apache.org/repos/asf/incubator/qpid/branches/M2.1 ........ r627552 - rgodfrey - 2008-02-13 18:10:53 +0000 (Wed, 13 Feb 2008) - 1 line ...  
r648218 aidan 2008-04-15 Merged revisions 647798-648216 via svnmerge from https://svn.apache.org/repos/asf/incubator/qpid/trunk ........ r647800 - gsim - 2008-04-14 14:57:36 +0100 (Mon, 14 Apr 2008) - 3 lines QPID-64 ...  
r648272 aconway 2008-04-15 Fix build error: MapValue SIZE was too small for Struct32.  
r648288 astitcher 2008-04-15 Refactored the IO framework that sits on top of Poller so that it uses a generalised IOHandle. This means that you can define new classes derived from IOHandle (other than Socket) that can also be add ...  
r648292 nsantos 2008-04-15 add svn revision include to specfile  
r648297 aconway 2008-04-15 Cleanup of size calculations and handling UnknownStruct  
r648308 nsantos 2008-04-15 QPID-921 : applied qpid-patch36.diff on behalf of Ted Ross  
r648314 aidan 2008-04-15 QPID-831 fix pom version  
r648328 aidan 2008-04-15 QPID-831 Remove some broker introspection stuff and transaction bumpf  
r648329 aconway 2008-04-15 Disabled failing tests, working on fixing the issues.  
r648338 aconway 2008-04-15 Comment out failing test, repairing.  
r648362 aconway 2008-04-15 Correct Struct32 encoding: size/code/data. Proper re-encoding for unknown struct codes.  
r648418 aconway 2008-04-15 Fix build error - missing op << for Struct32.  
r648614 rgodfrey 2008-04-16 QPID-899 : Bug in AMQShortString on tokenized substrings  
r648617 rgodfrey 2008-04-16 QPID-900 : Re-use byte[] of buffer for backing of AMQShortString  
r648637 rgodfrey 2008-04-16 QPID-922 : Selectors on header properties should not convert AMQShortStrings to Strings on every evaluation  
r648639 aidan 2008-04-16 QPID-916 add DISCLAIMER to top-level, make sure C++ and .Net archives are named correctly  
r648642 aidan 2008-04-16 QPID-916 tag RC6  
r648645 rgodfrey 2008-04-16 QPID-925 : Only begin store transactions when there is a persistent message to be committed  
r648648 rgodfrey 2008-04-16 QPID-926 : Perform all store operations associated with an acknowledge in a single store transaction  
r648652 rgodfrey 2008-04-16 QPID-927 : Multiple acknowledgements should be coalesced into single multiple ack  
r648658 rgodfrey 2008-04-16 QPID-929 : Exchange.Declare being sent prior to every message when publishing to explicit destination  
r648661 arnaudsimon 2008-04-16 QPID-928 Added a pause period for letting the finalyzer a chance to notify all the Mina connector threads before we check for spurious threads.  
r648666 rgodfrey 2008-04-16 QPID-931 : Always use exclusive consumers when subscribing to topics  
r648669 rgodfrey 2008-04-16 QPID-932 : Remove references to unusued constructor argument "browsedAcks" of NonTransactionalContext  
r648670 rgodfrey 2008-04-16 QPID-932 : Remove references to unusued constructor argument "browsedAcks" of NonTransactionalContext  
r648672 rgodfrey 2008-04-16 QPID-933 : performance tweaks  
r648678 aidan 2008-04-16 QPID-916 update dotnet NOTICE to include log4net, make sure DISCLAIMER is including in c++  
r648679 aidan 2008-04-16 QPID-916 delete, about to recreate  
r648680 aidan 2008-04-16 QPID-916 tag RC6  
r648681 arnaudsimon 2008-04-16 QPID-897 : this test was intermittently timing out when messages are not prefetched. This is a temporary fix until we use a configurable timeout.  
r648692 rhs 2008-04-16 QPID-901 : updates to the java client to use the 0-10 final spec instead of the 0-10 preview spec; this includes improvements to the codegen process as well as some modifications to the shared code pat ...  
r648699 rhs 2008-04-16 QPID-901 : add back ExceptionHelper.java to fix the build  
r648706 aconway 2008-04-16 Fix bug in Blob::assign assigning from an empty blob.  
r648724 aconway 2008-04-16 Fix encoding for sized structs.  
r648726 aconway 2008-04-16 Separate new codec from liqqpidcommon to improve link times. To be included in libqpidcommon when we are ready to replace framing codec.  
r648735 aidan 2008-04-16 QPID-832 fix exception constructors  
r648740 ritchiem 2008-04-16 QPID-886 : In order to allow the test to be written that highlights the failure we need to be able to provide a Config object not a file. So made the method public that reads the file and added constr ...  
r648764 aidan 2008-04-16 Rename in case of further M2-based releases  
r648770 aconway 2008-04-16 Removed complex_types.h from Makefile.am.  
r648771 rhs 2008-04-16 QPID-901 : don't depend on constant values matching up when converting between JMS and AMQP delivery modes  
r648782 aconway 2008-04-16 Add missing files to packaging.  
r648784 rhs 2008-04-16 QPID-901 : updated the JMS examples to use legal delivery mode values as they are now checked with the 0-10 final updates  
r648834 rgodfrey 2008-04-16 QPID-156 : Add an Apache licensed store - created an experimental Derby based store  
r648904 astitcher 2008-04-17 Refactored IO Thread creation so that it happens in the Broker class - There is now a single Poller created by the Broker class that is passed to the Acceptor for use in network IO. It can also now ...  
r649016 arnaudsimon 2008-04-17 QPID-919 Changed AMQBrokerDetails to throw an URL exception when the port number is not specified.  
r649055 aidan 2008-04-17 Track changes from M2.x now  
r649057 aidan 2008-04-17 Track changes from M2.x now  
r649058 aidan 2008-04-17 Track changes from M2.x now, with right svn  
r649059 gsim 2008-04-17 Some fixes to the transitional spec defs.  
r649070 arnaudsimon 2008-04-17 QPID-796 Made connection URL property + use session level method  
r649099 arnaudsimon 2008-04-17 QPID-884 Added cpp profile that does not use a store. Also updated profile for taking auth into account and updated broker.clean as per QPID-904  
r649126 nsantos 2008-04-17 add full path to qpidd in init script, as it fails in some environments with just the command name  
r649130 aconway 2008-04-17 Added missing .h files to Makefile.am to fix make rpmbuild. Add non-const Message::data() Make log/Statement.h public.  
r649132 aidan 2008-04-17 Merged revisions 632071-649058 via svnmerge from https://svn.apache.org/repos/asf/incubator/qpid/branches/M2.x ........ r632363 - ritchiem - 2008-02-29 16:00:19 +0000 (Fri, 29 Feb 2008) - 1 line ...  
r649141 aidan 2008-04-17 QPID-831 fix compile errors  
r649159 aconway 2008-04-17 src/Makefile.am: Fix problems with rpmbuild. src/tests/README: Updated information about boost test.  
r649294 astitcher 2008-04-17 Patch for improved compatibility with gcc 3.4 and boost 1.33  
r649339 aconway 2008-04-18 src/tests/python_tests: fix exit status if QPID_NO_PREVIEW is set. src/qpid/framing/AMQFrame.h: frame header setters/getters with 0-10 naming.  
r649409 arnaudsimon 2008-04-18 QPID-798 Make property per connection and/or system wide; change name to SYNC_PERSISTENT to denote only used on persistent messages Add accessor to Qpid test Case to allow prefetch to be turned on / off
r649432 aidan 2008-04-18 QPID-832 default protocol version to 0-9  
r649436 arnaudsimon 2008-04-18 QPID-936 : added missing session close op  
r649479 kpvdr 2008-04-18 Fix to prevent possible Timer deadlocks by holding onto mutex while calling fire()  
+ +

Review of New JIRAs

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Key Component(s) Affects Version/s Summary Status Assignee Reporter Review Comments
QPID-914 Python Client M3 (QPID-914) Separate python management component from core python client Open Rafael H. Schloming Gordon Sim  
QPID-915 C++ Broker   (QPID-915) A list of ways to avoid c++ and Python problems on the RHEL4 platform This is HTML, i.e. for a Wiki page. Closed Unassigned michael goulish  
QPID-916   M2.1 (QPID-916) Release M2.1 Open Aidan Skinner Aidan Skinner  
QPID-917 Python Client M1, M2, M2.1, M3 (QPID-917) python tests use the default, non-standard 'AMQPLAIN' as SASL mechanism Resolved Gordon Sim Gordon Sim  
QPID-918 C++ Broker M3 (QPID-918) Authentication password is logged when "trace" is enabled Open Unassigned Ted Ross  
QPID-919 Java Client M3 (QPID-919) Wrong exception thrown when the connection URL contains a broker name followed by ":" but no port number is specified. Open Arnaud Simon Arnaud Simon  
QPID-920 C++ Client M3 (QPID-920) Convert c++ client to final 0-10 spec Open Gordon Sim Gordon Sim  
QPID-921 C++ Broker, Python Client M3 (QPID-921) Management: persistent object-ids, SASL support, System-ID Closed Unassigned Ted Ross  
QPID-922 Java Broker M2.1 (QPID-922) (Java Broker) Selectors comparing header properties to constants always convert the property from AMQShortString to String, rather than converting the constant once Resolved Rob Godfrey Rob Godfrey  
QPID-923 Python Test Suite M2.1 (QPID-923) Python tests are not spec version aware Open Unassigned Martin Ritchie  
QPID-924 Ruby Test Suite M2.1 (QPID-924) Ruby test.rb use of '0.0.0.0' for localhost doesn't work under cygwin Open Unassigned Martin Ritchie  
QPID-925 Java Broker M2.1 (QPID-925) (Java Broker) Only begin store transactions when there is a persistent message to be committed Resolved Rob Godfrey Rob Godfrey  
QPID-926 Java Broker M2.1 (QPID-926) (Java Broker) Perform all store operations associated with an acknowledge in a single store transaction Open Rob Godfrey Rob Godfrey  
QPID-927   M2.1 (QPID-927) (Java Client) Multiple acknowledgements should be coalesced into single multiple ack, rather than each being sent individually Resolved Rob Godfrey Rob Godfrey  
QPID-928 Java Tests M3 (QPID-928) Test org.apache.qpid.test.unit.client.connection.ConnectionCloseTest intermittently failing Open Unassigned Arnaud Simon  
QPID-929 Java Client   (QPID-929) (Java Client) Exchange.Declare being sent prior to every message when publishing to explicit destination Resolved Rob Godfrey Rob Godfrey  
QPID-930 Ruby Client M1, M2, M2.1, M3 (QPID-930) ruby channel_close test issues Open Unassigned Gordon Sim  
QPID-931 Java Client M2.1 (QPID-931) (Java Client) Always use exclusive consumers when subscribing to topics Resolved Rob Godfrey Rob Godfrey  
QPID-932   M2.1 (QPID-932) (Java) Remove references to unusued constructor argument "browsedAcks" of NonTransactionalContext Open Rob Godfrey Rob Godfrey  
QPID-933 Java Broker, Java Client, Java Common M2.1 (QPID-933) (Java Performance) reduce memory copies, boxing/unboxing and needless iterating Resolved Rob Godfrey Rob Godfrey  
QPID-934 C++ Broker M3 (QPID-934) Federation tests fail intermittently Open Unassigned Ted Ross  
QPID-935    (QPID-935) patch to make trunk code work with old boost and gcc versions Open Unassigned michael goulish  
QPID-936 Java Tests M3 (QPID-936) Test testMigrateDurableSubscriber from org.apache.qpid.test.unit.xa.TopicTest is failing Open Unassigned Arnaud Simon  
QPID-937    (QPID-937) Typo in getting-started page of the site Open Unassigned Suran Jayathilaka  
+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Java Meeting Minutes 28-03-2008.html b/documentation/content/xdocs/Qpid Java Meeting Minutes 28-03-2008.html new file mode 100755 index 0000000000..7f23f7da68 --- /dev/null +++ b/documentation/content/xdocs/Qpid Java Meeting Minutes 28-03-2008.html @@ -0,0 +1,111 @@ + + + Apache Qpid : Qpid Java Meeting Minutes 28-03-2008 + + + + + + + + + +
+
+ + Apache Qpid : Qpid Java Meeting Minutes 28-03-2008 + +
+
+ This page last changed on Mar 28, 2008 by godfrer. +
+ +

Attendees

+ +

Rob Godfrey
+Arnaud Simon
+Aidan Skinner
+Marnie McCormack
+Rafi Schloming

+ +

Update on M2.1 release process

+ +

Tagged RC1 yesterday
+Going to run RAT, push out over the weekend
+Need to schedule updates to documentation

+ +

Update on GSoC projects

+ +

Had a large number of students, need to get mentors
+Need to distribute the load

+ +

Also have interest from external parties helping with management bridge

+ +

Need to follow the timeline; process

+ +

Apache Conn Europe

+ +

Qpid has a 15 min slot Amsterdam, Wednesday 9th April. Any volunteers?

+ +

Review of the previous week's commits

+

http://markmail.org/search/?q=type%3Acheckins+list%3Aorg.apache.incubator.qpid-commits+order%3Adate-forward+date%3A200803+#query:type%3Acheckins%20list%3Aorg.apache.incubator.qpid-commits%20order%3Adate-forward%20date%3A200803%20+page:13+mid:ewgbylgldnbmmqgw+state:results

+ +

r639619 : Rafi comments that there is a base class on trunk which should close all connections
+r640117 : We should standardize the comments on checkin to have QPID-xxx first, ensure case is correct
+r640422 : Should make timeouts a configuration parameter rather than picking arbitrary values; also allow non-timeout path coverage;
+r640434 : Need to look at logging levels for M3
+r640503 : no JIRA number associated with the checkin!
+r641212 : no need to be so generic, only need 32 bit serial numbers
+r641232 : incorrect capitalization

+ + + +

Review newly raised JIRAs

+ +

https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&type=-2&pid=12310520&created%3Aprevious=-1w+3d&sorter/field=issuekey&sorter/order=DESC

+ +

Update on what people are currently working on

+ +

MM: Looking at priorities for M3

+ +

AS: M2.1 and Merge

+ +

RG: Broker Refactoring
+ Headers/Exchange

+ +

ASimon: Adding DTX tests
+ See QPID-884
+ Fix the URL for backwards compatability - check version in protocol initiation
+ Configuration for prefetch in 0-10

+ +

RS: Updating 0-10 client to use correct 0-10 spec
+ large commit next week

+ +

Update on the merge from M2.1 to trunk (Aidan)

+ +

Will resynch broker / client after M2.1 finalised

+ +

Testing

+ +

Marnie will put up test spec
+Need to review to make sure all use cases covered.
+Need stress tests and soak tests
+Arnaud - should look at the Sonic test suite

+ + +

Meeting closed 15:30 UK

+ + + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Java Run Scripts.html b/documentation/content/xdocs/Qpid Java Run Scripts.html new file mode 100644 index 0000000000..99ee1788fd --- /dev/null +++ b/documentation/content/xdocs/Qpid Java Run Scripts.html @@ -0,0 +1,178 @@ + + + Apache Qpid : Qpid Java Run Scripts + + + + + + + + + +
+
+ + Apache Qpid : Qpid Java Run Scripts + +
+
+ This page last changed on Apr 06, 2007 by mmccorma. +
+ +

Qpid Java Broker Run Scripts

+ +

The following scripts are used to run the Qpid broker:

+ +

qpid-server
+qpid-server.bat
+qpid-run

+ +

These scripts are described in more detail below.

+ +

qpid-server

+ +

Overview

+ +

This script starts the Qpid Java Broker on Linux/Solaris/Cygwin platforms.

+ +

It is extremely simple, delegating the real work to the qpid-run script.

+ +

In fact, all it really provides is the main class to execute and passes through any command line arguments to qpid-run i.e.

+ +
+
. qpid-run org.apache.qpid.server.Main "$@"
+
+
+ +

qpid-server.bat

+ +

Overview

+ +

This script starts the Qpid Java Broker on Windows platforms. It provides a limited version of the qpid-run functionality, though is not nearly as sophisticated i.e. does not support run arguments or the full set of argument variables.

+ +

However, it does support the following features:

+ +
    +
  • validates that JAVA_HOME is set
    • +
  • validates that QPID_HOME is set
    • +
  • passes any command line arguments to the main broker class
    • +
  • supports the use of QPID_OPTS to pass through java system properties
    • +
+ + +

Note that a JIRA exists for enhancing the features this script supports http://issues.apache.org/jira/browse/QPID-168

+ +

qpid-run

+ +

Overview

+ +

The qpid-run script allows the calling program to run any given command, and provides a flexible surround supporting configurable runtime arguments for the script itself, the broker and java arguments.

+ +

Environment Variables and Defaulting

+ +

The variables noted below are used by the qpid-run script. Any default value used if not

+ +

specified is noted below.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
VariableDescriptionDefault
QPID_HOMEUsed as root for installed application path. Mandatory that users set thisNone
QPID_WORKUsed as root for any working directories to which the Qpid broker writes, for
+logging and bdb etc		Current User's Homedir
AMQJ_LOGGING_LEVELLogging level for broker codeinfo
QPID_LOG_PREFIXUsed as a prefix for qpid broker log, see FAQ for more detailsNone
QPID_LOG_SUFFIXUsed as a suffix for qpid broker log, see FAQ for more detailsNone
JPDA_OPTSIf set and -run:jpda argument provided used for debugging props, see belowNone
QPID_OPTSUse to pass custom system properties, including management console connection
+info		None
JAVA_OPTSUse to pass custom Java options, for example gc options etcNone
+ +

Run Arguments

+ +

You can provide run arguments to the qpid-run script using the syntax

+ +
+
-run:argument
+
+
+ +

The table below provides details of the available arguments.

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
ArgumentDescription
debugPrints classpath and command before running it
jpdaAdds remote debugging info using JPDA_OPTS. Use JPDA_TRANSPORT and JPDA_ADDRESS to
+customize, JPDA_OPTS to override
external-classpathValid values are: ignore, first, last and only. See below for more info
print-classpathPrints classpath before running command
helpPrints Usage information
+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Management Features.html b/documentation/content/xdocs/Qpid Management Features.html new file mode 100755 index 0000000000..654643d53e --- /dev/null +++ b/documentation/content/xdocs/Qpid Management Features.html @@ -0,0 +1,100 @@ + + + Apache Qpid : Qpid Management Features + + + + + + + + + +
+
+ + Apache Qpid : Qpid Management Features + +
+
+ This page last changed on Jul 04, 2007 by ritchiem. +
+ +

Management tool: Currently the management tool being used in development is JConsole.
+However, see this our Management Console page for details of how to use various console options with the Qpid management features.

+ +

The management of QPID is categorised into following types-

+
    +
  1. Exchange
    2. +
  2. Queue
    3. +
  3. Connection
    4. +
  4. Broker
    5. +
+ + +

 1) Managing and Monitoring Exchanges: Following is the list of features, which we can have available for managing and monitoring an Exchange running on a Qpid Server Domain-

+
    +
  1. Displaying the following information for monitoring purpose- +
      +
    1. The list of queues bound to the exchange along with the routing keys.
      2. +
    2. General Exchange properties(like name, durable etc).
      3. +
    +
    2. +
  2. Binding an existing queue with the exchange.
    3. +
+ + +

2) Managing and Monitoring Queues:  Following are the features, which we can have for a Queue on a Qpid Server Domain-

+
    +
  1. Displaying the following information about the queue for monitoring purpose- +
      +
    1. General Queue properties(like name, durable, etc.)
      2. +
    2. The maximum size of a message that can be accepted from the message producer.
      3. +
    3. The number of the active consumers accessing the Queue.
      4. +
    4. The total number of consumers (Active and Suspended).
      5. +
    5. The number of undelivered messages in the Queue.
      6. +
    6. The total number of messages received on the Queue since startup.
      7. +
    7. The maximum number of bytes for the Queue that can be stored on the Server.
      8. +
    8. The maximum number of messages for the Queue that can be stored on the Server.
      9. +
    +
    2. +
  2. Viewing the messages on the Queue.
    3. +
  3. Deleting message from top of the Queue.
    4. +
  4. Clearing the Queue.
    5. +
  5. Browsing the DeadMessageQueue - Messages which are expired or undelivered because of some reason are routed to the DeadMessageQueue.  This queue can not be deleted.  [Note: The is open because it depends on how these kind of messages will be handeled?]
    6. +
+ + +

3) Managing and Monitoring Connections: Following are the features, which we can have for a connection on a QPID Server Domain-

+
    +
  1. Displaying general connection properties(like remote address, etc.).
    2. +
  2. Setting maximum number of channels allowed for a connection.
    3. +
  3. View all related channels and channel properties.
    4. +
  4. Closing a channel.
    5. +
  5. Commit or Rollback transactions of a channel, if the channel is transactional.
    6. +
  6. Notification for exceeding the maximum number of channels.
    7. +
  7. Dropping a connection.
    8. +
+ + +

4) Managing the Broker: Features for the Broker-

+
    +
  1. Creating an Exchange.
    2. +
  2. Unregistering an Exchange.
    3. +
  3. Creating a Queue.
    4. +
  4. Deleting a Queue.        
    5. +
+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Python Documentation.html b/documentation/content/xdocs/Qpid Python Documentation.html new file mode 100755 index 0000000000..601dedf42f --- /dev/null +++ b/documentation/content/xdocs/Qpid Python Documentation.html @@ -0,0 +1,40 @@ + + + Apache Qpid : Qpid Python Documentation + + + + + + + + + +
+
+ + Apache Qpid : Qpid Python Documentation + +
+
+ This page last changed on Apr 13, 2008 by aidan. +
+ +

Qpid provides a python client library for sending messages over AMQP.

+ +

To use it, import qpid.*

+ +

See tests/basic.py for some trivial examples

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Release Notes.html b/documentation/content/xdocs/Qpid Release Notes.html new file mode 100755 index 0000000000..cecf6489a5 --- /dev/null +++ b/documentation/content/xdocs/Qpid Release Notes.html @@ -0,0 +1,36 @@ + + + Apache Qpid : Qpid Release Notes + + + + + + + + + +
+
+ + Apache Qpid : Qpid Release Notes + +
+
+ This page last changed on Nov 10, 2006 by mmccorma. +
+ +

Qpid Java M1 Release Notes

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Release Page.html b/documentation/content/xdocs/Qpid Release Page.html new file mode 100755 index 0000000000..59a027e1d3 --- /dev/null +++ b/documentation/content/xdocs/Qpid Release Page.html @@ -0,0 +1,60 @@ + + + Apache Qpid : Qpid Release Page + + + + + + + + + +
+
+ + Apache Qpid : Qpid Release Page + +
+
+ This page last changed on Apr 19, 2007 by mmccorma. +
+ +

Qpid Release Page

+ +

General Information

+

This page contains details about the Qpid release process.

+ + + +

Qpid Release Pages

+

These pages capture the requirments/feature list for each release.

+ + + + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Ruby Documentation.html b/documentation/content/xdocs/Qpid Ruby Documentation.html new file mode 100755 index 0000000000..581e3c015b --- /dev/null +++ b/documentation/content/xdocs/Qpid Ruby Documentation.html @@ -0,0 +1,36 @@ + + + Apache Qpid : Qpid Ruby Documentation + + + + + + + + + +
+
+ + Apache Qpid : Qpid Ruby Documentation + +
+
+ This page last changed on Apr 13, 2008 by aidan. +
+ +

Qpid supplies a ruby client for making AMQP connections to a compliant broker, require qpid.rb to get everything you need. tests/basic.rb has a simple example.

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Testing.html b/documentation/content/xdocs/Qpid Testing.html new file mode 100755 index 0000000000..be35e8ee7a --- /dev/null +++ b/documentation/content/xdocs/Qpid Testing.html @@ -0,0 +1,88 @@ + + + Apache Qpid : Qpid Testing + + + + + + + + + +
+
+ + Apache Qpid : Qpid Testing + +
+
+ This page last changed on Oct 30, 2006 by ritchiem. +
+ +

Overview

+ +

This is page summarises the various benchmark test that are actively run with Qpid.

+ +

Tests

+ + + + +

Servers

+ +

The results of the tests mean nothing without knowing what they were run on. Here is a list of the servers the project has available for testing use.
+The machines should be refered to in all tests.

+ + + + + + + + + + + + + + + +
ServerSpec
12.6.9-22.0.1.ELsmp - 8 - Way Opteron - 32 Gig Ram
22.4.21-15.0.4.ELhugemem - 4 - Way Opteron - 12 Gig Ram
+ +

Topic Test

+

Last Run : 2006-10-23

+ + + + + + + + + + +
ServersTiming
b1,c2avg: 778
+ +

IBM PutGet Test

+

Last Run :

+ +

IBM Sender/Receiver Test

+

Last Run :

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Qpid Troubleshooting Guide.html b/documentation/content/xdocs/Qpid Troubleshooting Guide.html new file mode 100755 index 0000000000..53f081604f --- /dev/null +++ b/documentation/content/xdocs/Qpid Troubleshooting Guide.html @@ -0,0 +1,83 @@ + + + Apache Qpid : Qpid Troubleshooting Guide + + + + + + + + + +
+
+ + Apache Qpid : Qpid Troubleshooting Guide + +
+
+ This page last changed on Oct 19, 2006 by mmccorma. +
+ +

I'm getting a java.lang.UnsupportedClassVersionError when I try to start the broker. What does this mean ?

+ +

The QPID broker requires JDK 1.5 or later. If you're seeing this exception you don't have that version in your path. Set JAVA_HOME to the correct version and ensure the bin directory is on your path.

+ +

java.lang.UnsupportedClassVersionError: org/apache/qpid/server/Main (Unsupported major.minor version 49.0)
+at java.lang.ClassLoader.defineClass(Ljava.lang.String;[BIILjava.security.ProtectionDomain;)Ljava.lang.Class;(Unknown Source)
+at java.security.SecureClassLoader.defineClass(Ljava.lang.String;[BIILjava.security.CodeSource;)Ljava.lang.Class;(SecureClassLoader.java:123)
+at java.net.URLClassLoader.defineClass(Ljava.lang.String;Lsun.misc.Resource;)Ljava.lang.Class;(URLClassLoader.java:251)
+at java.net.URLClassLoader.access$100(Ljava.net.URLClassLoader;Ljava.lang.String;Lsun.misc.Resource;)Ljava.lang.Class;(URLClassLoader.java:55)
+at java.net.URLClassLoader$1.run()Ljava.lang.Object;
+(URLClassLoader.java:194)
+at jrockit.vm.AccessController.do_privileged_exc(Ljava.security.PrivilegedExceptionAction;Ljava.security.AccessControlContext;I)Ljava.lang.Object;(Unknown Source)
+at jrockit.vm.AccessController.doPrivileged(Ljava.security.PrivilegedExceptionAction;Ljava.security.AccessControlContext;)Ljava.lang.Object;(Unknown Source)
+at java.net.URLClassLoader.findClass(Ljava.lang.String;)Ljava.lang.Class;(URLClassLoader.java:187)
+at java.lang.ClassLoader.loadClass(Ljava.lang.String;Z)Ljava.lang.Class; (Unknown Source)
+at sun.misc.Launcher$AppClassLoader.loadClass(Ljava.lang.String;Z)Ljava.lang.Class;(Launcher.java:274)
+at java.lang.ClassLoader.loadClass(Ljava.lang.String;)Ljava.lang.Class;
+(Unknown Source)
+at java.lang.ClassLoader.loadClassFromNative(II)Ljava.lang.Class;
+(Unknown Source)

+ +

I'm having a problem binding to the required host:port at broker startup ?

+ +

This error probably indicates that another process is using the port you the broker is trying to listen on. If you haven't amended the default configuration this will be 5672. To check what process is using the port you can use 'netstat -an |grep 5672'.

+ +

To change the port your broker uses, either edit the config.xml you are using. You can specify an alternative config.xml from the one provided in /etc by using the -c flag i.e. qpid-server -c <my config file path>.

+ +

You can also amend the port more simply using the -p option to qpid-server i.e. qpid-server -p <my port number'

+ +

I'm having problems with my classpath. How can I ensure that my classpath is ok ?

+ +

When you are running the broker the classpath is taken care of for you, via the manifest entries in the launch jars that the qpid-server configuration file adds to the classpath.

+ +

However, if you are running your own client code and experiencing classspath errors you need to ensure that the client-launch.jar from the installed Qpid lib directory is on your classpath. The manifest for this jar includes the common-launch.jar, and thus all the code you need to run a client application.

+ +

I can't get the broker to start. How can I diagnose the problem ?

+ +

Firstly have a look at the broker log file - either on stdout or in $QPID_WORK/log/qpid.log or in $HOME/log/qpid.log if you haven't set QPID_WORK.

+ +

You should see the problem logged in here via log4j and a stack trace. Have a look at the other entries on this page for common problems. If the log file includes a line like:

+ +

"2006-10-13 09:58:14,672 INFO [main] server.Main (Main.java:343) - Qpid.AMQP listening on non-SSL address 0.0.0.0/0.0.0.0:5672"

+ +

... then you know the broker started up. If not, then it didn't.

+ +

When I try to send messages to a queue I'm getting a error as the queue does not exist. What can I do ?

+ +

In Qpid queues need a consumer before they really exist, unless you have used the virtualhosts.xml file to specify queues which should always be created at broker startup. If you don't want to use this config, then simply ensure that you consume first from queue before staring to publish to it. See the entry on our Qpid Java FAQ for more details of using the virtualhosts.xml route.

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/QpidReleaseProcess.html b/documentation/content/xdocs/QpidReleaseProcess.html new file mode 100755 index 0000000000..4655891f6c --- /dev/null +++ b/documentation/content/xdocs/QpidReleaseProcess.html @@ -0,0 +1,178 @@ + + + Apache Qpid : QpidReleaseProcess + + + + + + + + + +
+
+ + Apache Qpid : QpidReleaseProcess + +
+
+ This page last changed on Apr 14, 2008 by aidan. +
+ +

Qpid Release Process - Background

+ +

Qpid Pre Release Steps

+ +

1. Create a wiki page and start capturing the feature/bug fix list for the release
+ 2. We can start a discussion thread and then come to a concensus on the final list
+ 3. These items should be tracked by jira or other means (jira is preffered)
+ 4. We can start a parallel thread on the release dates.

+ +

Detailed Qpid Release Process

+ +

1. We should do a code freeze and put out a release candidate (ex RC1)
+ 2. We should allow a minimum of one week for people to test/check out the RC
+ 3. If there are major issues maybe do a RC2 and follow the same process
+ 4. If a majority is happy then we can do a code freeze and cut out a release.
+ 5. We should provide a 1.4 retrotranslator build of the java client (only) with each release we make

+ +

Qpid Release Process - Our Process Definition

+ +

Introduction

+

This document describes the general release policies used by the Apache Qpid Project to create releases of the Qpid components. As described herein, this policy is not set in stone and may be adjusted by the Release Manager. We'd like to credit the Apache HTTPD project as our heavily borrowed from template for this document - thanks !

+ +

Who can make a release?

+

Technically, any one can make a release of the source code due to the Apache Software License. However, only members of the Apache Qpid Project (committers) can make a release designated with Apache. Other people must call their release something other than "Apache" unless they obtain written permission from the Apache Software Foundation.

+ +

Following our official release policies, we will only accept release binaries from members of the Apache Qpid Project for inclusion on our website. This ensures that our binaries can be supported by members of the project. Other people are free to make binaries, but we will not post them on our website.

+ +

Who is in charge of a release?

+

The release is coordinated by the Release Manager (hereafter, abbreviated as RM). Since this job requires coordination of the development community (and access to SVN), only committers to the project can be RM. However, there is no set RM. Any committer may perform a release at any time. In order to facilitate communication, it is deemed nice to alert the community with your planned release schedule before executing the release. A release should only be made when there is a plan to publicly release it. (A release should not be made only for private distribution. A private release is more suitable for that.)

+ +

Who may make a good candidate for an RM?

+

Someone with lots of time to kill. Being an RM is a very important job in our community because it takes a fair amount of time to produce a stable release.

+ +

If you feel lucky, a release could be distributed without testing, but our experience has shown that this leads to a higher number of dud releases. In general, our experience has shown that a well-coordinated release fares better than non-coordinated releases. For Qpid, we are yet to establish a quality bar for releases but it's on our list of things to do !

+ +

When do I know if it is a good time to release?

+

In the case of Qpid, we have identified (thus far) release cutoffs when we know that a) our codebase is fairly stable, b) we have made substantial improvements or additions since any previous release and c) we have significant change coming which would preclude a release for a significant period. M2 will be our second release from Qpid so this process is evolving.

+ +

What power does the RM yield?

+

Regarding what makes it into a release, the RM is the unquestioned authority. No one can contest what makes it into the release. The community will judge the release's quality after it has been issued, but the community can not force the RM to include a feature that they feel uncomfortable adding. Remember that

+ +

this document is only a guideline to the community and future RMs - each RM may run a release in a different way. If you don't like what an RM is doing, start preparing for your own competing release. Note that for Qpid we do tend to take votes for such items and follow the consensus.

+ +

How does an impending release affect development?

+

It can not. Let's repeat that: an impending release can not affect development of the project. It is the RM's responsibility to identify what changes should make it into the release. The RM may have an intermediate tag, so the RM can merge in or reject changes as they are committed to the repository's HEAD. For Qpid, we manage our releases using svn branches.

+ +

Committers may voluntarily refrain from committing patches if they wish to ease the burden on the RM, but they are under no obligation to do so. This is one reason why we recommend that the RMs have plenty of time on their hands - they may have to deal with a rapidly changing target. It's not an easy job.

+ +

How can an RM be confident in a release?

+

The RM may perform sanity checks on release candidates and should always ensure that (at least) the Qpid brokers being released can be started and connected to using test clients, before distributing. All maven available test classes should be run before releasing a distribution. The release candidate should pass all of the relevant tests before making it official. Note that we are currently in the process of defining a simple set of interop tests which ensure that our client/broker combinations can talk to one another.

+ +

How to do a release?

+

Once the tree has been suitably tested by the RM and any other interested parties, they should "roll" the release.

+ +

Key points:

+ +

Ensure that the RM's PGP/GPG key ?? - How do we do the key bit for Qpid ??
+Create an official tag based on the candidate tree
+Run the tools to build the appropriate binaries/source dists - details tbc
+Copy the generated release tarballs and signatures to - ?
+Email qpid-dev mailing list to inform them of the release

+ +

What can I call this release?

+

At this point, the release is an alpha. The Qpid Project has three classifications for its releases:

+ +

Should we adopt this ??
+Alpha
+Beta
+General Availability (GA)

+ +

Alpha indicates that the release is not meant for mainstream usage or may have serious problems that prohibits its use. When a release is initially created, it automatically becomes alpha quality.

+ +

Beta indicates that at least three committers have voted positively for beta status and there were more positive than negative votes for beta designation.

+ +

This indicates that it is expected to compile and perform basic tasks. However, there may be problems with this release that prohibit its widespread adoption.

+ +

General Availability (GA) indicates that at least three committers have voted positively for GA status and that there were more positive than negative votes for GA designation. This release is recommended for production usage.

+ +

Who can vote?

+

Non-committers may cast a vote for a release's quality. In fact, this is extremely encouraged as it provides much-needed feedback to the community about the release's quality. However, only binding votes casted by committers count towards the designation.

+ +

Note that no one may veto a release. Releases may not receive a designation level if a problem is found that inhibits proper functionality. The group may (implicitly or explicitly) revoke all votes on a release if there is a problem. However, if there is a -1 vote for a particular designation and there are greater than 3 positive votes and more positive than negative votes (i.e. majority consensus), the appropriate designation is conferred upon the release.

+ +

How do we make it public?

+

Once the release has reached the highest-available designation (as deemed by the RM), the release can be moved to the Qpid distribution directory on apache.org. Approximately 24 to 48 hours after the files have been moved, a public announcement can be made. We wait this period so that the mirrors can

+ +

receive the new release before the announcement. An email can then be sent to the announcements lists (announce@apache.org, announce@httpd.apache.org). Drafts of the announcement are usually posted on the development list before sending the announcement to let the community clarify any issues that we feel should be addressed in the announcement.

+ +

Should the announcement wait for binaries?

+

In short, no. The only files that are required for a public release are the source tarballs (.tar.Z, .tar.gz). Volunteers can provide the Win32 source distribution and binaries, and other esoteric binaries.

+ +

Note that the typical Win32 source distribution differs from the original tarball in that it has generated project files as well as the CRLF line endings required for that platform.

+ +

Oops. We found a problem.

+

At this point, the release has been created. No code changes can be made in this release. If a problem is found, it will have to be addressed in the next release or a patch can be made available. No changes can be made between alpha, beta, and GA status. The only difference is the file name that is downloaded

+ +

by the users. If an alpha tarball is created, but there was an error that can be resolved by re-rolling the tarball, it may be permissible to re-roll the release. But, the code itself may not change from designation to designation.

+ +

There are two courses of action:

+ +

Revoke the release and immediately create another one that has a fix to this problem. You can take the old release, apply the single patch, and start the voting process again. This is only recommended for critical problems found early on in the release cycle.

+ +

If the problem is less severe, place the patch to the problem in the Qpid patches directory TBC. A link to this directory should be included in the release notes with descriptions as to what problem each patch addresses.

+ +

Suggestions?

+

As always, if you have any suggestions or comments on our process, please feel free to email our developer mailing list (qpid-dev@incubator.apache.com) with your comments. We hope you found this document useful.

+ + +

M2.1 Release process

+ +

This is what I (aidan) ran to make the Qpid release artifacts:

+ +

aidan@contemplation:~/hacking/qpid$ mkdir RC5-artifacts
+aidan@contemplation:~/hacking/qpid$ svn co https://svn.apache.org/repos/asf/incubator/qpid/tags/M2.1/RC5/ qpid-M2.1-RC5
+aidan@contemplation:~/hacking/qpid$ ln -s qpid-M2.1-RC5 qpid-1.0-incubating-M2.1
+aidan@contemplation:~/hacking/qpid$ tar -hzcf RC5-artifacts/qpid-1.0-incubating-M2.1.tar.gz --exclude=.svn qpid-1.0-incubating-M2.1
+aidan@contemplation:~/hacking/qpid$ rm qpid-1.0-incubating-M2.1
+aidan@contemplation:~/hacking/qpid$ tar -zxf RC5-artifacts/qpid-1.0-incubating-M2.1.tar.gz
+aidan@contemplation:~/hacking/qpid$ cd qpid-1.0-incubating-M2.1/cpp
+aidan@contemplation:~/hacking/qpid/qpid-1.0-incubating-M2.1/cpp$ ./bootstrap && ./configure && make dist
+aidan@contemplation:~/hacking/qpid/qpid-1.0-incubating-M2.1/cpp$ cp qpidc-M2.1.tar.gz ../../RC5-artifacts/
+aidan@contemplation:~/hacking/qpid/qpid-1.0-incubating-M2.1/cpp$ cd ../java
+aidan@contemplation:~/hacking/qpid/qpid-1.0-incubating-M2.1/java$ mvn -Pfastinstall && cd distribution/ && mvn assembly:assembly
+aidan@contemplation:~/hacking/qpid/qpid-1.0-incubating-M2.1/java/distribution$ cp target/.gz target/.zip ../../../RC5-artifacts/
+aidan@contemplation:~/hacking/qpid/qpid-1.0-incubating-M2.1/java/distribution$ cd ../../dotnet/
+aidan@contemplation:/hacking/qpid/qpid-1.0-incubating-M2.1/dotnet$ sh ./build-framing && ./release mono-2.0 aidan@contemplation:/hacking/qpid/qpid-1.0-incubating-M2.1/dotnet$ cp bin/mono-2.0/release/Qpid.NET-mono-2.0-2008414.zip ../../RC5-artifacts/
+aidan@contemplation:~/hacking/qpid/qpid-1.0-incubating-M2.1/dotnet$ cd ../../
+aidan@contemplation:~/hacking/qpid$ tar -zcf RC5-artifacts/qpid-1.0-incubating-M2.1-python-src.tar.gz qpid-1.0-incubating-M2.1/LICENSE qpid-1.0-incubating-M2.1/NOTICE qpid-1.0-incubating-M2.1/python qpid-1.0-incubating-M2.1/specs
+aidan@contemplation:~/hacking/qpid$ tar -zcf RC5-artifacts/qpid-1.0-incubating-M2.1-ruby-src.tar.gz qpid-1.0-incubating-M2.1/LICENSE qpid-1.0-incubating-M2.1/NOTICE qpid-1.0-incubating-M2.1/ruby qpid-1.0-incubating-M2.1/specs
+aidan@contemplation:~/hacking/qpid$ cd qpid-1.0-incubating-M2.1/java/
+aidan@contemplation:~/hacking/qpid/qpid-1.0-incubating-M2.1/java$ mvn deploy -DaltDeploymentRepository=incubator::default::file:///home/aidan/hacking/qpid/RC5-artifacts/maven -Pfastinstall
+aidan@contemplation:~/hacking/qpid/qpid-1.0-incubating-M2.1/java$ cd ../../RC5-artifacts/
+aidan@contemplation:~/hacking/qpid/RC5-artifacts$ rm java-src console-unix
+aidan@contemplation:~/hacking/qpid/RC5-artifacts$ sha1sum *.zip *.gz > SHA1SUM
+aidan@contemplation:~/hacking/qpid/RC5-artifacts$ for i in `find . | egrep 'jar$|pom$|gz$|zip$|SHA1SUM'`; do gpg --sign --armor --detach $i; done;

+ +

and then rsync it up people.apache.org

+ +

--------------------------------------------------------------------------------

+ +

Copyright © 1999-2007, The Apache Software Foundation

+ + + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Queue Replay.html b/documentation/content/xdocs/Queue Replay.html new file mode 100755 index 0000000000..0cbaf38a18 --- /dev/null +++ b/documentation/content/xdocs/Queue Replay.html @@ -0,0 +1,190 @@ + + + Apache Qpid : Queue Replay + + + + + + + + + +
+
+ + Apache Qpid : Queue Replay + +
+
+ This page last changed on Feb 20, 2007 by ritchiem. +
+ +

Background

+ +

A lengthy discussion on replay in January 2007(page #7, Thread) highlighted a number of requirements and possible implementation options for adding replay to Qpid and AMQP. The requirements come from the desire to speed up the rate a consumer can read messages and to simplify its recovery when it starts. This page is to give some background, a proposal and finally some implementation options for discussion.

+ +

History

+ +

When a an application updates the state of a single Resource Manager, e.g a database or queue manager, it normally does so within the context of a local Transaction and this transaction exhibits the following ACID properties:

+ +
    +
  • Atomicity The result of the transaction are either all commited or all rolled back.
    • +
  • Consistency The completed transaction transformed the resource from one known state to another. Inserting a row into a database or removing a message from a queue are common examples.
    • +
  • Isolation Changes the the resources state effected by the transaction does not become visible ouside of the transaction until the transaction commits.
    • +
  • Durability The changes that reasult from the transactions commitment survive subsequent system or media faulures.
    • +
+ + +

Distributed Transaction

+ +

A distributed transaction is typically implemented by performing a Two Phase Commit (2PC) over which there are several varients the most well know being the X/Open XA specification. Where both the middleware and the consumer support XA, a separate Transaction Manager isused to coordinate the local transactions. The transaction manager coordinates atomicity at the global level whist each resource manager is responsible for the ACID properties of its local transactions.

+ +

These benefits do not come without cost.

+ +
    +
  • Increased transaction processing latency, typically due to the additional forced disk writes.
    • +
  • Applications can become blocked pending the resolution of an in-doubt global transaction.
    • +
  • Reduced concurrency
    • +
  • Multi-system deadlock
    • +
  • Administration complexity
    • +
  • Backing up the transaction manager involves co-ordinating all transaction logs at the same time or processing must be suspended.
    • +
+ + +

Idempotence and Replaying

+ +

When a message is being moved from system A to system B (e.g. from WebSphereMQ to ORACLE), distributed transactions can be avoided if;

+ +
    +
  • System B can handle duplicates (or can detect them and deal with them accordingly) - i.e. it is idempotent.
    • +
  • System A can replay messages from a known stable point in history.
    • +
+ + +

The most common way of doing this is simply managing the local transactions so that system B commits before system A. The start of replay is them the end of the last transaction on system A.

+ +

Typically a MOM will immediately delete a message once it has been commited by all of its consumers.

+ +

Commit is Not The End

+ +

If messages are made available for replay to a consumer after it has been commited, we can stretch the point in time the consumer recovers from back to any point.

+ +
    +
  • A few minutes ago
    • +
  • Trade ID FFS987654321
    • +
  • Start of day
    • +
  • End of yesterday
    • +
  • Friday.
    • +
+ + +

This larger recovery window lets downstream consumers the flexibility to recover from more failure scenarios.

+ +
    +
  • Retry an end of day batch job.
    • +
  • Replay due to reference data problem in target system.
    • +
  • Replay due to database or application failure.
    • +
+ + +

Replay as a First Class Service

+ +

When a traditional queue is opened for reading, it is opened and the next message is the oldest one that has not been destructively read (i.e. read and commited).

+ +

In isolation, a consumer manages its own local transactions with the message broker to confirm when a message or group of messages is processed, stored and stable. The local transaction leads to a disk write in the queue storage to mark the messages as read.

+ +

In this XA free world the consumer relys on the messaging to replay messages from the applications last good known state. As its always reading from a queue, the only extension to the queues semantics is to let it be opened for reading from a known message, irrespective of whether the message has been committed or not and it goes without saying that they should be in the same order in which they were originally delivered.

+ +

+ +

Many consumers of a guaranteed message flow are writing to a database and this database is the consumers view of its state, it's certainly where the consumer recovers from when it starts up. The traditional model of using a transaction manager, typically XA, to co-ordinate the local transactions on the database and messaging broker is slow and not without its problems.

+ +

+ +

Another model is to have the messaging infrastructure support replay of messages from a known point in history i.e. to correlate the current state of the consumers database with a last received message that last caused an update to the database from this channel. This is not an all encompassing pattern but rather compliments other ways to synchronize state between a message broker and a database.

+ +

+ +

Requirements

+ +
    +
  • Replay messages from a queue from a given message identified by a message ID or a header property.
    • +
  • Administrative support to purge messages from a queue as part of a business process such as End of Day
    • +
  • Zero impact on other queues and their consumers.
    • +
+ + +

Proposal: A Replayable Queue

+ +

Queues are the storage agents in AMQP so are the logical point to provide replay. A Replayable Queue (RQ) is not the default queue behavior but rather has to be explicitly configured. In may ways an RQ is somewhere between a traditional queue and a transaction log such as HOWL

+ +

An RQ has the following properties:

+ +
    +
  • An RQ can only have a single consumer. Multiple consumers complicate the problem so I propose discounting them for now.
    • +
  • Messages are not deleted when consumed by a regular consumer. The act of acknowledging the message is just another property on the message. Indeed, the consumer may never acknowledge the message as this implies a write on the message broker to update the messages state.
    • +
  • When an RQ is opened for reading, the consumer must give a selector that will identify a point in the queue to begin message delivery from.
    • +
  • Administratively defined points in the queue exist. These points can be defined by an administration API and associated tooling and used as points to replay from.
    • +
  • Queues are purged of messages by the administration API or associated tooling. This allows external processes such as End of Day to initiate message archiving or deletion when it is safe to do so.
    • +
  • An RQ can be replicated. Implementation options? SAN replication, dual writes?
    • +
+ + +

Benefits

+ +
    +
  • An RQ, by virtue of a single consumer, does not need to be written to when a consumer reads messages as it is the responsibility of the consumer to provide the synchronization point when it first connects. This can significantly speed up the consumer as its bottleneck will be its own database write.
    • +
+ + +
    +
  • A complete record of all messaging activity is available.
    • +
+ + +

Downsides

+ +
    +
  • The size of the store needs careful management so any implementation details do not cause performance issues.
    • +
+ + +

Implementation Options in Qpid.

+ +

Configuration

+ +

Storage

+ +

Management

+ +

Usage from JMS

+ +
+
+ Attachments: +
+ +
+ + TraditionalQueueWithTX.gif (image/gif) +
+ + TraditionalQueue.gif (image/gif) +
+ + ReplayableQueue.gif (image/gif) +
+
+ +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Queue Replay_attachments/ReplayableQueue.gif b/documentation/content/xdocs/Queue Replay_attachments/ReplayableQueue.gif new file mode 100755 index 0000000000..69f4744e61 Binary files /dev/null and b/documentation/content/xdocs/Queue Replay_attachments/ReplayableQueue.gif differ diff --git a/documentation/content/xdocs/Queue Replay_attachments/TraditionalQueue.gif b/documentation/content/xdocs/Queue Replay_attachments/TraditionalQueue.gif new file mode 100755 index 0000000000..12e0d45271 Binary files /dev/null and b/documentation/content/xdocs/Queue Replay_attachments/TraditionalQueue.gif differ diff --git a/documentation/content/xdocs/Queue Replay_attachments/TraditionalQueueWithTX.gif b/documentation/content/xdocs/Queue Replay_attachments/TraditionalQueueWithTX.gif new file mode 100755 index 0000000000..040d0c43aa Binary files /dev/null and b/documentation/content/xdocs/Queue Replay_attachments/TraditionalQueueWithTX.gif differ diff --git a/documentation/content/xdocs/RAJB.html b/documentation/content/xdocs/RAJB.html new file mode 100755 index 0000000000..6e57b201a0 --- /dev/null +++ b/documentation/content/xdocs/RAJB.html @@ -0,0 +1,47 @@ + + + Apache Qpid : RAJB + + + + + + + + + +
+
+ + Apache Qpid : RAJB + +
+
+ This page last changed on Apr 11, 2008 by cctrieloff. +
+ + +

General User Guides Java

+ + + + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/RASC.html b/documentation/content/xdocs/RASC.html new file mode 100755 index 0000000000..5ae7e2dc49 --- /dev/null +++ b/documentation/content/xdocs/RASC.html @@ -0,0 +1,191 @@ + + + Apache Qpid : RASC + + + + + + + + + +
+
+ + Apache Qpid : RASC + +
+
+ This page last changed on Apr 12, 2008 by cctrieloff. +
+ +

Running the C++ Broker

+ +

It is really simple, to run cmd line

+
+
./qpidd
+
+

to run as a daemon process

+
+
./qpidd --daemon
+
+

stopping the daemon

+
+
./qpidd --quit
+
+ +

Most common questions getting qpidd running

+ +

No data directory

+ +

The qpidd broker requires you to setup a data directory or specify --no-data-dir (see help for more details). Best
+is to make sure that you have create a data directory for qpidd that the process has permissions to write to.

+ +

The default location is

+
+
/lib/var/qpidd
+
+ +

An alternate location can be set with --data-dir

+ +

Starting qpidd and it says the that process is already locked

+ +

Note that when qpidd starts it creates a lock file is data directory are being used. If you have a un-controlled exit, please mail
+the trace from the core to the qpid-dev@i.a.o mailing list. To clear the lock run

+ +
+
./qpidd -q
+
+ +

It should also be noted that multiple brokers can be run on the same host. To do so set alternate data directories for each qpidd instance.

+ +

Using the conf file

+ +

In order to use the conf file, use the same options that are on the command line

+
+
./qpidd --help
+
+ +

but formated in the following way.
+ a.) remove the '--' from the beginning of the option.
+ b.) place a '=' between the option and the value.
+ c.) place one option per line.

+ +

Can I use any Language client with the C++ Broker

+ +

Yes, all the clients work with the C++ broker. The only restriction is that the client that matches the AMQP version needed to be used. When running the C++ broker, it is highly recommended to run AMQP 0-10.

+ +

Note that JMS also works with the C++ broker. For more details on using the Java client refer to these pages:

+ + + +

Slightly more complex configuration

+ +

The easiest way to get a full listing of the broker's options are to use the --help command, run it locally for the latest set of options. These options can then be set in the conf file for convenience (see above)

+ +
+
./qpidd --help
+
+Usage: qpidd OPTIONS
+Options:
+  -h [ --help ]                    Displays the help message
+  -v [ --version ]                 Displays version information
+  --config FILE (/etc/qpidd.conf)  Reads configuration from FILE
+
+Module options:
+  --module-dir DIR (/usr/lib/qpidd)  Load all .so modules in this directory
+  --load-module FILE                 Specifies additional module(s) to be loaded
+  --no-module-dir                    Don't load modules from module directory
+
+Broker Options:
+  --data-dir DIR (/var/lib/qpidd)   Directory to contain persistent data generated by the broker
+  --no-data-dir                     Don't use a data directory.  No persistent
+                                    configuration will be loaded or stored
+  -p [ --port ] PORT (5672)         Tells the broker to listen on PORT
+  --worker-threads N (3)            Sets the broker thread pool size
+  --max-connections N (500)         Sets the maximum allowed connections
+  --connection-backlog N (10)       Sets the connection backlog limit for the
+                                    server socket
+  --staging-threshold N (5000000)   Stages messages over N bytes to disk
+  -m [ --mgmt-enable ] yes|no (1)   Enable Management
+  --mgmt-pub-interval SECONDS (10)  Management Publish Interval
+  --ack N (0)                       Send session.ack/solicit-ack at least every
+                                    N frames. 0 disables voluntary ack/solitict
+                                   -ack
+
+Daemon options:
+  -d [ --daemon ]             Run as a daemon.
+  -w [ --wait ] SECONDS (10)  Sets the maximum wait time to initialize the
+                              daemon. If the daemon fails to initialize, prints
+                              an error and returns 1
+  -c [ --check ]              Prints the daemon's process ID to stdout and
+                              returns 0 if the daemon is running, otherwise
+                              returns 1
+  -q [ --quit ]               Tells the daemon to shut down
+Logging options:
+  --log-output FILE (stderr)  Send log output to FILE. FILE can be a file name
+                              or one of the special values:
+                              stderr, stdout, syslog
+  -t [ --trace ]              Enables all logging
+  --log-enable RULE (error+)  Enables logging for selected levels and component
+                              s. RULE is in the form 'LEVEL+:PATTERN'
+                              Levels are one of:
+                              trace debug info notice warning error critical
+                              For example:
+                              '--log-enable warning+' logs all warning, error
+                              and critical messages.
+                              '--log-enable debug:framing' logs debug messages
+                              from the framing namespace. This option can be
+                              used multiple times
+  --log-time yes|no (1)       Include time in log messages
+  --log-level yes|no (1)      Include severity level in log messages
+  --log-source yes|no (0)     Include source file:line in log messages
+  --log-thread yes|no (0)     Include thread ID in log messages
+  --log-function yes|no (0)   Include function signature in log messages
+
+ +

Loading extra modules

+ +

By default the broker will load all the modules in the module directory, however it will NOT display options for modules that are not loaded. So to see the options for extra modules loaded you need to load the module and then add the help command like this:

+
+
./qpidd --load-module libbdbstore.so --help
+Usage: qpidd OPTIONS
+Options:
+  -h [ --help ]                    Displays the help message
+  -v [ --version ]                 Displays version information
+  --config FILE (/etc/qpidd.conf)  Reads configuration from FILE
+
+
+ / .... non module options would be here ... /
+
+
+Store Options:
+  --store-directory DIR     Store directory location for persistence (overrides
+                            --data-dir)
+  --store-async yes|no (1)  Use async persistence storage - if store supports
+                            it, enables AIO O_DIRECT.
+  --store-force yes|no (0)  Force changing modes of store, will delete all
+                            existing data if mode is changed. Be SURE you want
+                            to do this!
+  --num-jfiles N (8)        Number of files in persistence journal
+  --jfile-size-pgs N (24)   Size of each journal file in multiples of read
+                            pages (1 read page = 64kiB)
+
+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/RC Multi-Platform Testing.html b/documentation/content/xdocs/RC Multi-Platform Testing.html new file mode 100755 index 0000000000..690292a2b5 --- /dev/null +++ b/documentation/content/xdocs/RC Multi-Platform Testing.html @@ -0,0 +1,48 @@ + + + Apache Qpid : RC Multi-Platform Testing + + + + + + + + + +
+
+ + Apache Qpid : RC Multi-Platform Testing + +
+
+ This page last changed on Oct 19, 2006 by mmccorma. +
+ +

Any QPID release candidate should be tested on the following supported platforms:

+ +
    +
  • Linux 2.6+
    • +
  • Windows XP 5+
    • +
  • Solaris 8 (SunOS 5.8)+
    • +
  • Cygwin v?
    • +
+ + +

It shall be a quality gateway for any RC that it must run successfully (define tests here ?) on all platforms supported. All scripts will run successfully on these platforms (*.sh on all unix/linux style OSs and *.bat on Windows).

+ +

Multi-platform operability is a key attribute for QPID users and thus we must ensure that changes applied do not compromise this.

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Release Plans.html b/documentation/content/xdocs/Release Plans.html new file mode 100755 index 0000000000..42a7ee30ef --- /dev/null +++ b/documentation/content/xdocs/Release Plans.html @@ -0,0 +1,46 @@ + + + Apache Qpid : Release Plans + + + + + + + + + +
+
+ + Apache Qpid : Release Plans + +
+
+ This page last changed on Oct 31, 2006 by mmccorma. +
+ +

Currently we have tentative plans for the following releases of the Qpid Java Broker & Client:

+ +

M1 - November 2006

+ +

The content for this release is available via our JIRA release notes:

+ +

https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12312115&styleName=Html&projectId=12310520

+ +

M2 - December 2006

+ +

Details of content tbc shortly.

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Reliability Requirements.html b/documentation/content/xdocs/Reliability Requirements.html new file mode 100755 index 0000000000..9cdf026009 --- /dev/null +++ b/documentation/content/xdocs/Reliability Requirements.html @@ -0,0 +1,96 @@ + + + Apache Qpid : Reliability Requirements + + + + + + + + + +
+
+ + Apache Qpid : Reliability Requirements + +
+
+ This page last changed on Jun 11, 2007 by aconway. +
+ +

Reliability Requirements

+ + +

Fail-over (session state)

+ +

A cluster member informs its clients of backup candidates for each session. It can update the list periodically.

+ +

After an unexpected disconnect the client can connect to one of the candidates and resume its session transparently. All session state is preserved including:

+
    +
  • Open references
    • +
  • Active consumers
    • +
  • Commands-in-flight
    • +
  • Open transactions (question: Is there any value in fail-over that aborts TX and/or DTX transactions?)
    • +
+ + +

Sessions do not survive

+
    +
  • multiple failures that include the current node and all back-up nodes for that session.
    • +
  • shutdown/restart of the cluster.
    • +
+ + +

Cluster Restart (durable resources)

+ +

The AMQP entities that survive a restart are those defined by AMQP to survive broker restart. AMQP defines durable exchanges and queues and persistent messages. Some further definitions:

+
    +
  • durable message: persistent messages on a durable queues.
    • +
  • durable enque: act of enqueuing a persistent message on a durable queue.
    • +
  • durable binding: binding between durable exchange and durable queue.
    • +
+ + +

The following are preserved if the entire cluster shuts down/crashes and is re-started:

+
    +
  • Durable wiring: durable exchanges, queues and bindings.
    • +
  • Durable messages
    • +
  • Prepared DTX transactions
    • +
+ + +

The following do not survive a restart:

+
    +
  • Session state
    • +
  • Non-durable wiring
    • +
  • TX transactions are aborted.
    • +
  • Unprepared DTX transactions are aborted.
    • +
  • Non-durable effects of prepared DTX transactions are lost.
    • +
+ + +

Restarting DTX Transactions

+ +

On restart, prepared DTX transactions may commit or rollback. In either case the outcome is as if the transaction had comitted or rolled back just before the restart: All durable transaction effects survive the restart, all non-durable effects are lost.

+ +

In particular

+
    +
  • On commit: non durable messages enqueued in the transaction are lost, as if they had been enqueued before the restart and were lost in the restart.
    • +
  • On rollback: non durable messages dequeued in the transaction are lost, as if they had been put back on the queue before restart and then lost in the restart.
    • +
+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Restructuring Java Broker and Client Design_attachments/AMQ Frame handling b/documentation/content/xdocs/Restructuring Java Broker and Client Design_attachments/AMQ Frame handling new file mode 100755 index 0000000000..da5d22eb40 --- /dev/null +++ b/documentation/content/xdocs/Restructuring Java Broker and Client Design_attachments/AMQ Frame handling @@ -0,0 +1 @@ +A new Gliffy diagram

]]> \ No newline at end of file diff --git a/documentation/content/xdocs/Restructuring Java Broker and Client Design_attachments/ContentHandlerTree.jpg b/documentation/content/xdocs/Restructuring Java Broker and Client Design_attachments/ContentHandlerTree.jpg new file mode 100755 index 0000000000..74a4d52c36 Binary files /dev/null and b/documentation/content/xdocs/Restructuring Java Broker and Client Design_attachments/ContentHandlerTree.jpg differ diff --git a/documentation/content/xdocs/Restructuring Java Broker and Client Design_attachments/DispatchTree.jpg b/documentation/content/xdocs/Restructuring Java Broker and Client Design_attachments/DispatchTree.jpg new file mode 100755 index 0000000000..2217045f51 Binary files /dev/null and b/documentation/content/xdocs/Restructuring Java Broker and Client Design_attachments/DispatchTree.jpg differ diff --git a/documentation/content/xdocs/Restructuring Java Broker and Client Design_attachments/MethodHandlerTree.jpg b/documentation/content/xdocs/Restructuring Java Broker and Client Design_attachments/MethodHandlerTree.jpg new file mode 100755 index 0000000000..442843f143 Binary files /dev/null and b/documentation/content/xdocs/Restructuring Java Broker and Client Design_attachments/MethodHandlerTree.jpg differ diff --git a/documentation/content/xdocs/ReturnStdStringByValue.html b/documentation/content/xdocs/ReturnStdStringByValue.html new file mode 100755 index 0000000000..e393018fa9 --- /dev/null +++ b/documentation/content/xdocs/ReturnStdStringByValue.html @@ -0,0 +1,54 @@ + + + Apache Qpid : ReturnStdStringByValue + + + + + + + + + +
+
+ + Apache Qpid : ReturnStdStringByValue + +
+
+ This page last changed on Oct 19, 2006 by mmccorma. +
+ +

Don't do this:

+
+
std::string& f();
+const std::string& g(); // Not much better
+
+

Instead do this:

+
+
std::string f();
+std::string g();
+
+ +

std::string is designed expressly to allow you to treat strings as simple pass-by-value types, like int. It's efficient to return by value rather than reference and it avoids core dumps if the real string hidden away in f gets deleted before the reference. In particular it allows f() to compute once-off values and forget about them, e.g.:

+ +
+
std::string hello(const std::string& name) { return "hello " + name; }
+
+ +

With the "&" style return this would be an immediate disaster as the returned reference is invalid before the caller even gets it! NB. The last example contains another error! See BewareOfStringPromotion.

+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/ScopedLocking.html b/documentation/content/xdocs/ScopedLocking.html new file mode 100755 index 0000000000..95796e6f94 --- /dev/null +++ b/documentation/content/xdocs/ScopedLocking.html @@ -0,0 +1,52 @@ + + + Apache Qpid : ScopedLocking + + + + + + + + + +
+
+ + Apache Qpid : ScopedLocking + +
+
+ This page last changed on Oct 19, 2006 by mmccorma. +
+ +

Always use scoped lockers to lock mutexes and the like. Don't do this:

+
+
 lock.acquire();
+ do_stuff(); // DANGER: lock never released if exception thrown here.
+ lock.release();
+
+
+ +

Instead use a "scoped locker". This is simply a class that does the "acquire" in its constructor and the "release" in its destructor:

+
+
  Locker locker(lock);
+  do_stuff();
+
+
+ +

Not only does this save a bit of typing, it guarantees that the lock will be released even if an exception is thrown, because C++ guarantees to call destructors of all local variables on exit from a scope. This also protects you forgetting to release the lock at every exit point from a function with multiple exit points - the compiler takes care of it for you. This technique applies more generally to any situation where you have to acquire and release resources. std::auto_ptr is a similar tool for memory management.

+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Setup .Net Client on Windows.html b/documentation/content/xdocs/Setup .Net Client on Windows.html new file mode 100755 index 0000000000..8bc6836130 --- /dev/null +++ b/documentation/content/xdocs/Setup .Net Client on Windows.html @@ -0,0 +1,50 @@ + + + Apache Qpid : Setup .Net Client on Windows + + + + + + + + + +
+
+ + Apache Qpid : Setup .Net Client on Windows + +
+
+ This page last changed on Aug 02, 2007 by ritchiem. +
+ +

Setup

+ +

Install:
+ Microsoft Visual Studio 2005 (VS2005)
+ NAnt 0.85 - only required for builds outside VS2005 (.net 1.1, .net 2.0, mono 2.0)
+ Ant 1.6.5
+ Cygwin (or alternatively build via cmd but alter instructions below accordingly)

+ +

Set up PATH to include Nant.exe:

+ +

$ PATH=/cygdrive/c/WINDOWS/Microsoft.NET/Framework/v2.0.50727:$PATH

+ +

Set up PATH to include ant:

+ +

$ PATH=$ANT_HOME/bin:$PATH

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/SharedPtr.html b/documentation/content/xdocs/SharedPtr.html new file mode 100755 index 0000000000..31effc4389 --- /dev/null +++ b/documentation/content/xdocs/SharedPtr.html @@ -0,0 +1,71 @@ + + + Apache Qpid : SharedPtr + + + + + + + + + +
+
+ + Apache Qpid : SharedPtr + +
+
+ This page last changed on Oct 19, 2006 by mmccorma. +
+ +

std::tr1::shared_ptr is an almost-standard smart pointer template that
+provides unintrusive reference-counting semantics for any class. It
+almost makes memory management too easy for a C++ programmer.

+ +

It's available in g++ and some other compilers by default. There are
+several open source implementations if we ever port to a compiler that
+doesn't have it.

+ +

The golde rule: if class Foo has shared ownership then never ever
+write Foo*. Anywhere. Ever. Use shared_ptr in all function
+signatures and variables, use std::tr1::dynamic_pointer_cast and
+friends for casting.

+ +

Qpid will use it for all classes with shared ownership semantics,
+enforced by private constructors and static factory functions. We'll
+also adopt the convention to typedef shared_ptr within the class for
+convenience. E.g.

+ +
+
class Foo {
+   Foo() { ... }
+
+ public:
+   typedef std::tr1::shared_ptr<Foo> shared_ptr;
+   static shared_ptr create() { return new Foo() }
+   // .. a create for each constructor.
+}
+
+Foo::shared_ptr p = Foo::create();  // etc...
+
+ + +

There's a good article at http://www.boost.org/libs/smart_ptr/sp_techniques.html.

+ + + + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Source Repository.html b/documentation/content/xdocs/Source Repository.html new file mode 100755 index 0000000000..71011d2d06 --- /dev/null +++ b/documentation/content/xdocs/Source Repository.html @@ -0,0 +1,63 @@ + + + Apache Qpid : Source Repository + + + + + + + + + +
+
+ + Apache Qpid : Source Repository + +
+
+ This page last changed on Jan 08, 2007 by cctrieloff. +
+ +

Web Browsing of SVN

+ +

To browse via the web use the ViewVC interface:

+ +

http://svn.apache.org/viewvc/incubator/qpid/trunk/qpid

+ +

Or to browse the source tree directly:

+ +

https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid

+ +

Checking out from SVN

+ +

The source code can be checked out anonymous over HTTP by doign:

+
+
svn co http://svn.apache.org/repos/asf/incubator/qpid/trunk
+
+ +

Committers can check out the code over HTTPS:

+
+
svn co https://svn.apache.org/repos/asf/incubator/qpid/trunk
+
+ +

Setting up your subversion client

+ +

When adding files to subversion, it's important that your subversion client is properly setup to the appropriate subversion properties are set. The client can do it automatically by modifying the auto-props section of the subversion config file. Use the contents of:

+
+
http://svn.apache.org/repos/asf/incubator/qpid/trunk/etc/svn-auto-props
+
+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Sustained Tests.html b/documentation/content/xdocs/Sustained Tests.html new file mode 100755 index 0000000000..2e929f4207 --- /dev/null +++ b/documentation/content/xdocs/Sustained Tests.html @@ -0,0 +1,98 @@ + + + Apache Qpid : Sustained Tests + + + + + + + + + +
+
+ + Apache Qpid : Sustained Tests + +
+
+ This page last changed on Jun 27, 2007 by ritchiem. +
+ +

Pub/Sub Sustained Tests

+ +

We currently have one sustained test for pub / sub messaging. The test is based on the interop testing framework and as such there are two classes that are involve.

+ +
    +
  1. org.apache.qpid.sustained.TestClient
    2. +
  2. org.apache.qpid.sustained.TestCoordinator
    3. +
+ + +

As with the Interop Tests the Test Coordinator collects various clients to work on the specified test. The sustained test suit currently only has one test which is the SustainedTestClient.

+ +

SustainedTestClient Test

+ +

This test is a pub/sub test. There is a single publisher that sends batches of messages to a known topic. The clients then receive these messages and report the time required to retrive all of the batch. This reported time is sent to the publisher so that it can adjust its publication rate to ensure that messages are sent at a rate that all clients can maintain.

+ +

Usage

+

The coordinator can take a number of parameters.

+ +
    +
  • numReceives (Default : 2)
    +This is the number of receivers each client node should create
    • +
  • batchSize (Default : 1000)
    +This is the number of messages to send per batch
    • +
  • ackMode (Default : 1 - AUTO_ACK )
    +The acknowledgement mode to use. Currently No_ack (257) appears not to work correctly.
    • +
+ + + +

The client can take the following system parameters (set via -D properties)
+(These values should be moved to the Coordinator so that you do not need to guess which client will become the sender as these values are only of use to the sending client.)

+ +
    +
  • sleepPerMessage (Default : false)
    +Divides the current _delay value into small sleeps between messages. Useful if your Thread.sleep implementation works at the nanosecond level. Under windows the smallest sleep value is around 10ms.
    • +
  • warmUpBatches (Default : 10)
    +Adjusts the number of batches sent before resetting the delay calculations.
    • +
  • stableReportCount (Default : 5)
    +The number of reports that need to arrive without changing the delay before reporting the delay is stable.
    • +
  • batchVariance (Default : 3)
    +The difference between the batch number sent and the received batch number.
    • +
+ + +

The client also has one additional parameter.

+ +
    +
  • "-j" can be used to join an existing test run. Dispite there being only one test case at present this class must be provided as future sustained test classes may be available. +
    +
    java -cp <qpid.jar> org.apache.qpid.sustained.TestClient -n client2 -j org.apache.qpid.performance.sustainedrate.SustainedTestClient
+
    +
    • +
+ + +

It is important to remember that each cilent must be uniquly named for the test to accurately work. This can be done by ensuring that all clients specify a unique "-n" value. So running

+
+
java -cp <qpid.jar> org.apache.qpid.sustained.TestClient -n client2 
+
+
+ +

Will correctly name the client 'client2' and attempt to joint the client to any running SustainedTestClient test. If there is no test running then the client will simply wait for the test to start.

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Test Server 1.html b/documentation/content/xdocs/Test Server 1.html new file mode 100755 index 0000000000..558a94d78e --- /dev/null +++ b/documentation/content/xdocs/Test Server 1.html @@ -0,0 +1,100 @@ + + + Apache Qpid : Test Server 1 + + + + + + + + + +
+
+ + Apache Qpid : Test Server 1 + +
+
+ This page last changed on Oct 30, 2006 by ritchiem. +
+ +

uname -a

+
+
Linux amq01.XXXX.com 2.6.9-22.0.1.ELsmp #1 SMP Tue Oct 18 18:39:02 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux
+
+
+ + +

cpuinfo

+

8 times:

+
+
vendor_id       : AuthenticAMD
+cpu family      : 15
+model           : 33
+model name      : AMD Opteron (tm) Processor 850
+stepping        : 0
+cpu MHz         : 2199.994
+cache size      : 1024 KB
+physical id     : 0
+siblings        : 2
+core id         : 0
+cpu cores       : 2
+fpu             : yes
+fpu_exception   : yes
+cpuid level     : 1
+wp              : yes
+flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext lm 3dnowext 3dnow pni fid
+bogomips        : 4325.37
+TLB size        : 1088 4K pages
+clflush size    : 64
+cache_alignment : 64
+address sizes   : 40 bits physical, 48 bits virtual
+power management: ts fid vid ttp
+
+
+
+ +

meminfo

+
+
MemTotal:     32752424 kB
+MemFree:      12768520 kB
+Buffers:        108600 kB
+Cached:        6014696 kB
+SwapCached:      88572 kB
+Active:       10993568 kB
+Inactive:      5376292 kB
+HighTotal:           0 kB
+HighFree:            0 kB
+LowTotal:     32752424 kB
+LowFree:      12768520 kB
+SwapTotal:     4192956 kB
+SwapFree:      3818360 kB
+Dirty:             764 kB
+Writeback:           0 kB
+Mapped:       10247920 kB
+Slab:           403688 kB
+Committed_AS: 19979696 kB
+PageTables:      31164 kB
+VmallocTotal: 536870911 kB
+VmallocUsed:      3060 kB
+VmallocChunk: 536867383 kB
+HugePages_Total:  1536
+HugePages_Free:   1536
+Hugepagesize:     2048 kB
+
+
+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Test Server 2.html b/documentation/content/xdocs/Test Server 2.html new file mode 100755 index 0000000000..fb18e8da43 --- /dev/null +++ b/documentation/content/xdocs/Test Server 2.html @@ -0,0 +1,98 @@ + + + Apache Qpid : Test Server 2 + + + + + + + + + +
+
+ + Apache Qpid : Test Server 2 + +
+
+ This page last changed on Oct 30, 2006 by ritchiem. +
+ +

uname -a

+
+
Linux cc01.XXX.com 2.4.21-15.0.4.ELhugemem #1 SMP Sat Jul 31 01:16:24 EDT 2004 i686 athlon i386 GNU/Linux
+
+
+
+ +

cpuinfo

+

4 times:

+
+
vendor_id       : AuthenticAMD
+cpu family      : 15
+model           : 5
+model name      : AMD Opteron(tm) Processor 852
+stepping        : 1
+cpu MHz         : 2592.647
+cache size      : 1024 KB
+physical id     : 0
+siblings        : 1
+runqueue        : 3
+fdiv_bug        : no
+hlt_bug         : no
+f00f_bug        : no
+coma_bug        : no
+fpu             : yes
+fpu_exception   : yes
+cpuid level     : 1
+wp              : yes
+flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall mmxext lm 3dnowext 3dnow
+bogomips        : 5177.34
+
+
+
+ +

meminfo

+
+
        total:    used:    free:  shared: buffers:  cached:
+Mem:  16854679552 11465375744 5389303808        0 208089088 8931819520
+Swap: 2146689024        0 2146689024
+MemTotal:     16459648 kB
+MemFree:       5262992 kB
+MemShared:           0 kB
+Buffers:        203212 kB
+Cached:        8722480 kB
+SwapCached:          0 kB
+Active:        6059460 kB
+ActiveAnon:     268656 kB
+ActiveCache:   5790804 kB
+Inact_dirty:   2544200 kB
+Inact_laundry: 1869136 kB
+Inact_clean:       132 kB
+Inact_target:  2094584 kB
+HighTotal:    12680640 kB
+HighFree:      3630216 kB
+LowTotal:      3779008 kB
+LowFree:       1632776 kB
+SwapTotal:     2096376 kB
+SwapFree:      2096376 kB
+HugePages_Total:     0
+HugePages_Free:      0
+Hugepagesize:     2048 kB
+
+
+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/The AMQP Distributed Transaction Classes.html b/documentation/content/xdocs/The AMQP Distributed Transaction Classes.html new file mode 100755 index 0000000000..ef548e7443 --- /dev/null +++ b/documentation/content/xdocs/The AMQP Distributed Transaction Classes.html @@ -0,0 +1,83 @@ + + + Apache Qpid : The AMQP Distributed Transaction Classes + + + + + + + + + +
+
+ + Apache Qpid : The AMQP Distributed Transaction Classes + +
+
+ This page last changed on May 31, 2007 by cctrieloff. +
+ +

The distributed transaction classes provide support for the X-Open XA architecture. The dtx-demarcation class is used to demarcate transaction boundaries on a given channel that is subsequently used to perform AMQP native transactional work (produce publish messages). Transaction coordination and recovery operations are provided by the dtx-coordination class.

+ +

A Transaction Manager uses RM Client XA interface to demarcate transaction boundaries and coordinate transaction outcomes. RM Clients use the dtx-demarcation class to associate transactional work with a transactional channel. The transactional channel is exposed to the application driving the transaction. The application can then use the transactional channel to transactionally produce and consume messages. RM clients use dtx-coordination to propagate transaction outcomes and recovery operations to the AMQP broker. A second coordination channel can be used for that purpose.

+ +

More details about can be found at:

+ + + +

The Qpid Implementation

+

As shown on the following class diagram, there are two protocol specific dtx classes, that is to say DtxDemarcation and DtxCoordination that are highlighted in yellow.

+ +

+ + +

DtxDemarcation

+

DtxDemarcation interacts with the corresponding AMQChannel. The operation select creates the corresponding TransactionalContext (a channel has by default a non-transactional context). The operations start and end associate and disassociate a provided xid with the current TransactionalContext that percolates the call to the TransactionManager (operations begin and end respectively). Note that the operation end is responsible for acknowledging the messages against the context i.e. those messages are seen as being consumed under the currently associated xid.

+ +

DtxCoordination

+

DtxCoordination directly interacts with the TransactionManager. Note that it is a requirement that the operation end is called on all involved channels (i.e. all the acknowledged messages have been specifically consumed under the provided xid).

+ +

TransactionalContext

+

There are three flavours of TransactionalContext: the non transactional one, the local and distributed ones. The distributed and local contexts are very similar and both extend the abstract context. Note that the distributed context does not implement commit and rollback as this is DtxCoordination that is responsible for deciding of a transaction outcome.

+ +

TransactionManager and MessageStore

+

Transaction manager and message store are linked as the message store may need to add transaction records to the transaction identified by a given xid. Moreover, the transaction manager may need to use the transactional facilities of the underlying store. This is the case of the JDBCStore and JDBCTransactionManager. The JDBCTransactionManager uses the transaction facilities of the JDBCStore for performing ACID operations during prepare and commit.

+ +

This is the responsibility of the MessageStore to recover queues and exchanges and messages. Note that the JDBCTransactionManager delegates the responsibility of getting the list of in-doubt transactions to the JDBCStore but another implementation of TransactionManager may handle that directly.
+The MessageStore implementation should not load the messages in memory during recovery but only set the messageID. The message header, publish info and payload are lazily loaded. Note that the message payloads are currently loaded in memory. We can however easily implement a direct streaming of message payload on the wire (The MessageStore interface can be extended for supporting that).

+ +
+
+ Attachments: +
+ +
+ + dtx-classes-presentation-v0.10-PMC-03142007.pdf (application/pdf) +
+ + dtx-classes-specification-document-v1.2.pdf (application/pdf) +
+ + 12358547_thumb_dtx.gif (image/gif) +
+
+ +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/The AMQP Distributed Transaction Classes_attachments/12358547_thumb_dtx.gif b/documentation/content/xdocs/The AMQP Distributed Transaction Classes_attachments/12358547_thumb_dtx.gif new file mode 100755 index 0000000000..e4907ff6e7 Binary files /dev/null and b/documentation/content/xdocs/The AMQP Distributed Transaction Classes_attachments/12358547_thumb_dtx.gif differ diff --git a/documentation/content/xdocs/The AMQP Distributed Transaction Classes_attachments/dtx-classes-presentation-v0.10-PMC-03142007.pdf b/documentation/content/xdocs/The AMQP Distributed Transaction Classes_attachments/dtx-classes-presentation-v0.10-PMC-03142007.pdf new file mode 100755 index 0000000000..811f941b6d Binary files /dev/null and b/documentation/content/xdocs/The AMQP Distributed Transaction Classes_attachments/dtx-classes-presentation-v0.10-PMC-03142007.pdf differ diff --git a/documentation/content/xdocs/The AMQP Distributed Transaction Classes_attachments/dtx-classes-specification-document-v1.2.pdf b/documentation/content/xdocs/The AMQP Distributed Transaction Classes_attachments/dtx-classes-specification-document-v1.2.pdf new file mode 100755 index 0000000000..1fa4d0e638 Binary files /dev/null and b/documentation/content/xdocs/The AMQP Distributed Transaction Classes_attachments/dtx-classes-specification-document-v1.2.pdf differ diff --git a/documentation/content/xdocs/Topic Test.html b/documentation/content/xdocs/Topic Test.html new file mode 100755 index 0000000000..bcaf3399bf --- /dev/null +++ b/documentation/content/xdocs/Topic Test.html @@ -0,0 +1,109 @@ + + + Apache Qpid : Topic Test + + + + + + + + + +
+
+ + Apache Qpid : Topic Test + +
+
+ This page last changed on Oct 30, 2006 by ritchiem. +
+ +

Topic Test

+ +

This test is tests the time taken for a publisher to send out m messages, to l (ell) listeners and gather their responses. The average time to receive the report from the listeners is displayed at the end of the run. Additional runs or batches can be performed with the average value being displayed at the end of the run.

+ +

Configuration

+ +

The standard configuration for this test is to use the following:

+ +
    +
  • 10 Clients
    • +
  • 20 Batches
    • +
  • 10,000 Messages
    • +
+ + +

The broker is setup and run on a seperate box(b1) connected via Gigabit ethernet. The 10 listeners and the publisher were all run on the same box (c2)

+ +

Command lines

+ +

Broker

+
+
./qpid-server -c `pwd`/../etc/config-5670-MMS.xml  -l ../etc/log4j.off.xml
+
+
+ +

Listeners

+
+
./topicListener -host <host>
+
+
+

equivalent to

+
+
 ./run_many.sh 10 lists 'java -server -Dlog4j.configuration=file://`pwd`/../etc/log4j.off.xml -Xmx256m org.apache.qpid.topic.Listener -host <host> -messages 10000'
+
+
+ + +

Publisher

+
+
./topicPublisher -host <host> -messages 10000 -batch 20 -clients 10
+
+
+

equivalent to

+
+
java -server -Dlog4j.configuration=file://`pwd`/../etc/log4j.off.xml -Xmx256m org.apache.qpid.topic.Publisher -host <host> -messages 10000 -batch 20 -clients 10
+
+
+ +

Topic Test Results

+

For Server list see main Qpid Testing page.

+ +

r466127

+ + + + + + + + + + + + + + + + + + + + + +
ServersRunTimings
b1,c2r1min: 1527, max: 8397 avg: 1491
b1,c2r2min: 1462, max: 7876 avg: 1472
b1,c2r3min: 1491, max: 8234 avg: 1494
+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/URL Formats.html b/documentation/content/xdocs/URL Formats.html new file mode 100755 index 0000000000..b2216c5913 --- /dev/null +++ b/documentation/content/xdocs/URL Formats.html @@ -0,0 +1,43 @@ + + + Apache Qpid : URL Formats + + + + + + + + + +
+
+ + Apache Qpid : URL Formats + +
+
+ This page last changed on Apr 02, 2008 by asimon. +
+ +

URL Format for connections and binding

+

There are currently two formats implemented in the Java code base. One is for connection and the other is an exchange binding URL. The URL formats have been designed around the Java URI format. This allows the parsing majority of the parsing work to be handled for us.

+ + + + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Useful Links.html b/documentation/content/xdocs/Useful Links.html new file mode 100755 index 0000000000..ab70509a40 --- /dev/null +++ b/documentation/content/xdocs/Useful Links.html @@ -0,0 +1,38 @@ + + + Apache Qpid : Useful Links + + + + + + + + + +
+
+ + Apache Qpid : Useful Links + +
+
+ This page last changed on Oct 19, 2006 by mmccorma. +
+ +

Purpose

+ +

Links to related projects/useful stuff for developers

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Using Qpid with other JNDI Providers.html b/documentation/content/xdocs/Using Qpid with other JNDI Providers.html new file mode 100755 index 0000000000..0b46fc3a3a --- /dev/null +++ b/documentation/content/xdocs/Using Qpid with other JNDI Providers.html @@ -0,0 +1,137 @@ + + + Apache Qpid : Using Qpid with other JNDI Providers + + + + + + + + + +
+
+ + Apache Qpid : Using Qpid with other JNDI Providers + +
+
+ This page last changed on Jun 22, 2007 by ritchiem. +
+ + +

How to use a JNDI Provider

+ +

Qpid will work with any JNDI provider capable of storing Java objects. We have a task to add our own initial context factory, but until that's available ....

+ +

First you must select a JNDI provider to use. If you aren't already using an application server (i.e. Tomcat ?) which provides JNDI support you could consider using either:

+
    +
  • Apache's Directory which provides an LDAP JNDI implementation
    • +
+ + + + + +
    +
  • Click : Download JNDI 1.2.1 & More button
    • +
  • Download: File System Service Provider, 1.2 Beta 3
    • +
  • and then add the two jars in the lib dir to your class path.
    • +
+ + +

There are two steps to using JNDI objects.

+
    +
  • Bind : Which stores a reference to a JMS Object in the provider.
    • +
  • Lookup : Which tries to retrieve the reference and create the JMS Object.
    • +
+ + +

There are two objects that would normally be stored in JNDI.

+
    +
  • A ConnectionFactory
    • +
  • A Destination (Queue or Topic)
    • +
+ + +

Binding

+ +

Then you need to setup the values that the JNDI provider will used to bind your references, something like this:

+
Setup JNDI
+
Hashtable env = new Hashtable(11);
+  env.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.fscontext.RefFSContextFactory");
+  env.put(Context.PROVIDER_URL,LOCAL_FILE_PATH_FOR_STORING_BINDS_PATH_MUST_EXIST);
+
+

These values are then used to create a context to bind your references.

+
Perform Binding of ConnectionFactory
+
try
+{
+    Context ctx = new InitialContext(env);
+
+    // Create the object to be bound in this case a ConnectionFactory
+    ConnectionFactory factory = null;
+
+    try
+    {
+        factory = new AMQConnectionFactory(CONNECTION_URL);
+        try
+        {
+            ctx.bind(binding, factory);
+        }
+        catch (NamingException e)
+        {
+            //Handle problems with binding. Such as the binding already exists.
+        }
+    }
+    catch (URLSyntaxException amqe)
+    {
+        //Handle any exception with creating ConnnectionFactory
+    }
+}
+catch (NamingException e)
+{
+    //Handle problem creating the Context.
+}
+
+

To bind a queue instead simply create a AMQQueue object and use that in the binding call.

+
Bind a AMQQueue
+
AMQQueue  queue = new AMQQueue(QUEUE_URL);
+ctx.bind(binding, queue);
+
+ +

Lookup

+ +

You can then get a queue connection factory from the JNDI context.

+
Perform Binding of ConnectionFactory
+
ConnectionFactory factory;
+try
+{
+    factory= (ConnectionFactory)ctx.lookup(binding);
+}
+catch (NamingException e)
+{
+    //Handle problems with lookup. Such as binding does not exist.
+}
+
+

Note that you need not cast the bound object back to an AMQConnectionFactory so all your current JMS apps that use JNDI can start using Qpid straight away.

+ + +

How to create a TopicConnectionFactory and QueueConnectionFactory

+ +

AMQConnectionFactory implements TopicConnectionFactory and QueueConnectionFactory as well as the ConnectionFactory.

+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/ValgrindBadSuppressions.html b/documentation/content/xdocs/ValgrindBadSuppressions.html new file mode 100755 index 0000000000..d7c8221b47 --- /dev/null +++ b/documentation/content/xdocs/ValgrindBadSuppressions.html @@ -0,0 +1,61 @@ + + + Apache Qpid : ValgrindBadSuppressions + + + + + + + + + +
+
+ + Apache Qpid : ValgrindBadSuppressions + +
+
+ This page last changed on Mar 28, 2007 by aconway. +
+ +

(Observed with valgrind 3.2.1, fixed in 3.2.3)
+Valgrind 3.2.1 sometimes produces supressions that don't work, like this:

+
+
{
+  <insert a suppression name here>
+  Memcheck:Free
+  fun:_vgrZU_libcZdsoZa_free
+  fun:main
+}
+
+

The identifying characteristic is that they begin with fun:_vg<something>

+ +

http://article.gmane.org/gmane.comp.debugging.valgrind/5939 explains what these symbols are.

+ +

The workaround is to replace fun:vg*_lib*<something> with fun:<something>, where something
+should be a valid C or C++ mangled symbol.

+ +

The following test program demonstrates the problem

+
+
#include <stdlib.h>
+int main(int argc,char**argv) {
+   char*p = malloc(10);
+   free(p);
+   free(p);
+}
+
+ + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/Weekly QPID Developer Meetings.html b/documentation/content/xdocs/Weekly QPID Developer Meetings.html new file mode 100755 index 0000000000..692fab8ead --- /dev/null +++ b/documentation/content/xdocs/Weekly QPID Developer Meetings.html @@ -0,0 +1,36 @@ + + + Apache Qpid : Weekly QPID Developer Meetings + + + + + + + + + +
+
+ + Apache Qpid : Weekly QPID Developer Meetings + +
+
+ This page last changed on Mar 28, 2008 by godfrer. +
+ + + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/add.gif b/documentation/content/xdocs/add.gif new file mode 100755 index 0000000000..252d7ebcb8 Binary files /dev/null and b/documentation/content/xdocs/add.gif differ diff --git a/documentation/content/xdocs/border/border_bottom.gif b/documentation/content/xdocs/border/border_bottom.gif new file mode 100755 index 0000000000..b93012ac2a Binary files /dev/null and b/documentation/content/xdocs/border/border_bottom.gif differ diff --git a/documentation/content/xdocs/border/spacer.gif b/documentation/content/xdocs/border/spacer.gif new file mode 100755 index 0000000000..fc2560981e Binary files /dev/null and b/documentation/content/xdocs/border/spacer.gif differ diff --git a/documentation/content/xdocs/icons/blogentry_16.gif b/documentation/content/xdocs/icons/blogentry_16.gif new file mode 100755 index 0000000000..83d600d097 Binary files /dev/null and b/documentation/content/xdocs/icons/blogentry_16.gif differ diff --git a/documentation/content/xdocs/icons/bullet_blue.gif b/documentation/content/xdocs/icons/bullet_blue.gif new file mode 100755 index 0000000000..25bfa0cf2b Binary files /dev/null and b/documentation/content/xdocs/icons/bullet_blue.gif differ diff --git a/documentation/content/xdocs/icons/comment_16.gif b/documentation/content/xdocs/icons/comment_16.gif new file mode 100755 index 0000000000..6f76e86bd7 Binary files /dev/null and b/documentation/content/xdocs/icons/comment_16.gif differ diff --git a/documentation/content/xdocs/icons/emoticons/add.gif b/documentation/content/xdocs/icons/emoticons/add.gif new file mode 100755 index 0000000000..0c00fe0d49 Binary files /dev/null and b/documentation/content/xdocs/icons/emoticons/add.gif differ diff --git a/documentation/content/xdocs/icons/emoticons/biggrin.gif b/documentation/content/xdocs/icons/emoticons/biggrin.gif new file mode 100755 index 0000000000..ad04031985 Binary files /dev/null and b/documentation/content/xdocs/icons/emoticons/biggrin.gif differ diff --git a/documentation/content/xdocs/icons/emoticons/check.gif b/documentation/content/xdocs/icons/emoticons/check.gif new file mode 100755 index 0000000000..28bb99943f Binary files /dev/null and b/documentation/content/xdocs/icons/emoticons/check.gif differ diff --git a/documentation/content/xdocs/icons/emoticons/error.gif b/documentation/content/xdocs/icons/emoticons/error.gif new file mode 100755 index 0000000000..6d68a8cc0b Binary files /dev/null and b/documentation/content/xdocs/icons/emoticons/error.gif differ diff --git a/documentation/content/xdocs/icons/emoticons/forbidden.gif b/documentation/content/xdocs/icons/emoticons/forbidden.gif new file mode 100755 index 0000000000..c6acdec605 Binary files /dev/null and b/documentation/content/xdocs/icons/emoticons/forbidden.gif differ diff --git a/documentation/content/xdocs/icons/emoticons/help_16.gif b/documentation/content/xdocs/icons/emoticons/help_16.gif new file mode 100755 index 0000000000..83387c25c6 Binary files /dev/null and b/documentation/content/xdocs/icons/emoticons/help_16.gif differ diff --git a/documentation/content/xdocs/icons/emoticons/information.gif b/documentation/content/xdocs/icons/emoticons/information.gif new file mode 100755 index 0000000000..072ab660fa Binary files /dev/null and b/documentation/content/xdocs/icons/emoticons/information.gif differ diff --git a/documentation/content/xdocs/icons/emoticons/lightbulb.gif b/documentation/content/xdocs/icons/emoticons/lightbulb.gif new file mode 100755 index 0000000000..cd72409a47 Binary files /dev/null and b/documentation/content/xdocs/icons/emoticons/lightbulb.gif differ diff --git a/documentation/content/xdocs/icons/emoticons/lightbulb_on.gif b/documentation/content/xdocs/icons/emoticons/lightbulb_on.gif new file mode 100755 index 0000000000..3768ef7d12 Binary files /dev/null and b/documentation/content/xdocs/icons/emoticons/lightbulb_on.gif differ diff --git a/documentation/content/xdocs/icons/emoticons/sad.gif b/documentation/content/xdocs/icons/emoticons/sad.gif new file mode 100755 index 0000000000..6aca31070f Binary files /dev/null and b/documentation/content/xdocs/icons/emoticons/sad.gif differ diff --git a/documentation/content/xdocs/icons/emoticons/smile.gif b/documentation/content/xdocs/icons/emoticons/smile.gif new file mode 100755 index 0000000000..f8dc2782a0 Binary files /dev/null and b/documentation/content/xdocs/icons/emoticons/smile.gif differ diff --git a/documentation/content/xdocs/icons/emoticons/star_blue.gif b/documentation/content/xdocs/icons/emoticons/star_blue.gif new file mode 100755 index 0000000000..9b366cebeb Binary files /dev/null and b/documentation/content/xdocs/icons/emoticons/star_blue.gif differ diff --git a/documentation/content/xdocs/icons/emoticons/star_green.gif b/documentation/content/xdocs/icons/emoticons/star_green.gif new file mode 100755 index 0000000000..42d27ec7e8 Binary files /dev/null and b/documentation/content/xdocs/icons/emoticons/star_green.gif differ diff --git a/documentation/content/xdocs/icons/emoticons/star_red.gif b/documentation/content/xdocs/icons/emoticons/star_red.gif new file mode 100755 index 0000000000..c10acb9f7d Binary files /dev/null and b/documentation/content/xdocs/icons/emoticons/star_red.gif differ diff --git a/documentation/content/xdocs/icons/emoticons/star_yellow.gif b/documentation/content/xdocs/icons/emoticons/star_yellow.gif new file mode 100755 index 0000000000..0f1d151a32 Binary files /dev/null and b/documentation/content/xdocs/icons/emoticons/star_yellow.gif differ diff --git a/documentation/content/xdocs/icons/emoticons/thumbs_down.gif b/documentation/content/xdocs/icons/emoticons/thumbs_down.gif new file mode 100755 index 0000000000..855c748864 Binary files /dev/null and b/documentation/content/xdocs/icons/emoticons/thumbs_down.gif differ diff --git a/documentation/content/xdocs/icons/emoticons/thumbs_up.gif b/documentation/content/xdocs/icons/emoticons/thumbs_up.gif new file mode 100755 index 0000000000..7c55feebd8 Binary files /dev/null and b/documentation/content/xdocs/icons/emoticons/thumbs_up.gif differ diff --git a/documentation/content/xdocs/icons/emoticons/tongue.gif b/documentation/content/xdocs/icons/emoticons/tongue.gif new file mode 100755 index 0000000000..fe77df2fa2 Binary files /dev/null and b/documentation/content/xdocs/icons/emoticons/tongue.gif differ diff --git a/documentation/content/xdocs/icons/emoticons/warning.gif b/documentation/content/xdocs/icons/emoticons/warning.gif new file mode 100755 index 0000000000..1c9883b8f7 Binary files /dev/null and b/documentation/content/xdocs/icons/emoticons/warning.gif differ diff --git a/documentation/content/xdocs/icons/emoticons/wink.gif b/documentation/content/xdocs/icons/emoticons/wink.gif new file mode 100755 index 0000000000..24bdea9605 Binary files /dev/null and b/documentation/content/xdocs/icons/emoticons/wink.gif differ diff --git a/documentation/content/xdocs/icons/home_16.gif b/documentation/content/xdocs/icons/home_16.gif new file mode 100755 index 0000000000..7a902b1be9 Binary files /dev/null and b/documentation/content/xdocs/icons/home_16.gif differ diff --git a/documentation/content/xdocs/icons/linkext7.gif b/documentation/content/xdocs/icons/linkext7.gif new file mode 100755 index 0000000000..f2dd2dcfa9 Binary files /dev/null and b/documentation/content/xdocs/icons/linkext7.gif differ diff --git a/documentation/content/xdocs/icons/mail_16.gif b/documentation/content/xdocs/icons/mail_16.gif new file mode 100755 index 0000000000..0386c0d105 Binary files /dev/null and b/documentation/content/xdocs/icons/mail_16.gif differ diff --git a/documentation/content/xdocs/icons/mail_small.gif b/documentation/content/xdocs/icons/mail_small.gif new file mode 100755 index 0000000000..a3b7d9f06f Binary files /dev/null and b/documentation/content/xdocs/icons/mail_small.gif differ diff --git a/documentation/content/xdocs/icons/user_12.gif b/documentation/content/xdocs/icons/user_12.gif new file mode 100755 index 0000000000..d41511f1b8 Binary files /dev/null and b/documentation/content/xdocs/icons/user_12.gif differ diff --git a/documentation/content/xdocs/icons/user_16.gif b/documentation/content/xdocs/icons/user_16.gif new file mode 100755 index 0000000000..f5a2fb6a3a Binary files /dev/null and b/documentation/content/xdocs/icons/user_16.gif differ diff --git a/documentation/content/xdocs/index.html b/documentation/content/xdocs/index.html new file mode 100755 index 0000000000..5c53f3ddcf --- /dev/null +++ b/documentation/content/xdocs/index.html @@ -0,0 +1,709 @@ + + + + + qpid (Apache Qpid) Test + + + + + + + + + +
+
+

Space Details:

+
+ + + + + + + + + + + + + + + + + + + + + +
+ Key: + qpid
+ Name: + Apache Qpid
+ Description: +

The Qpid Project provides an open and interoperable, multiple language implementations of the Advanced Messaged Queuing Protocol (AMQP) specification and related technologies including PGM, transaction management, queuing, distribution, security, management and heterogeneous multi-platform support for messaging.

+ Creator (Creation Date): + husted (Oct 06, 2006)
+ Last Modifier (Mod. Date): + rgreig (Oct 17, 2006)
+
+
+

+

Available Pages:

+ +

+
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/reconnect.gif b/documentation/content/xdocs/reconnect.gif new file mode 100755 index 0000000000..e2f8c3e1fe Binary files /dev/null and b/documentation/content/xdocs/reconnect.gif differ diff --git a/documentation/content/xdocs/roadmap.html b/documentation/content/xdocs/roadmap.html new file mode 100755 index 0000000000..7374b42890 --- /dev/null +++ b/documentation/content/xdocs/roadmap.html @@ -0,0 +1,100 @@ + + + Apache Qpid : roadmap + + + + + + + + + +
+
+ + Apache Qpid : roadmap + +
+
+ This page last changed on Mar 27, 2008 by cctrieloff. +
+ + +

M2.1

+ +

M2.1 is a maintainer release for the M2 code branch. The detailed breakdown of JIRA's for M2.1 can be found here:

+ +

This release implements the the AMQP 0-9 protocol version

+ + +

http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310520&fixfor=12312720

+ + +

M3 – Current development release

+ +

This release implements the AMQP 0-9 & AMQP 0-10 protocol versions

+ +

Top level themes for this release:

+ +
    +
  • C++ broker supporting AMQP 0-10
    • +
  • C++ client supporting AMQP 0-10
    • +
  • Java Client support AMQP 0-9 (M2.1) and AMQP 0-10
    • +
  • Python Client supporting AMQP 0-9 (M2.1) and AMQP 0-10 (in addition to older versions)
    • +
  • Landing the Big merge on Java Broker
    • +
  • Ruby Client updated to AMQP 0-10 — Nice task to start on
    • +
  • .NET Client updated to AMQP 0-10 — Nice task to start on
    • +
  • Federation
    • +
  • Transparent 0.8/0.9/.10 support in the Java broker (might need to be M4)
    • +
+ + +

The following are nice task to pick up for new committers: (Please mail the list if you have interest in doing any of these

+ +
    +
  • Creation of Perl Client — Nice task to start on
    • +
  • AMQP-MGMT to WS-DM and JMX bridge — Nice task to start on
    • +
  • Integrating AMQP-MGMT into the Java broker
    • +
  • Windows Client C++ support
    • +
  • Solaris Client C++ support
    • +
  • Writing examples and getting started pages — Nice task to start on
    • +
  • Help update this site — Nice task to start on
    • +
  • Profiling for performance improvements
    • +
+ + +

Slightly more involved items

+ +
    +
  • Message Priority - both brokers
    • +
  • Java broker tasks +
      +
    • Add Flow To Disk
      • +
    • Message Federation for Java (Fan out & forward to remote queue) – look at C++ broker and impl in Java (might need to wait for 0-10 (M4))
      • +
    • Flow control - throttling of overactive producers – might need 0-10 (M4)
      • +
    +
    • +
  • JCA / App server integrations
    • +
  • Spring integration
    • +
+ + + +

JIRA for M3:

+ +

http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310520&fixfor=12312117

+ + + +
+ + + + + + + +
Document generated by Confluence on Apr 22, 2008 02:47
+ + \ No newline at end of file diff --git a/documentation/content/xdocs/site.xml b/documentation/content/xdocs/site.xml new file mode 100755 index 0000000000..e8720b7cc0 --- /dev/null +++ b/documentation/content/xdocs/site.xml @@ -0,0 +1,146 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/documentation/content/xdocs/styles/site.css b/documentation/content/xdocs/styles/site.css new file mode 100755 index 0000000000..94e93af5a6 --- /dev/null +++ b/documentation/content/xdocs/styles/site.css @@ -0,0 +1,1511 @@ +body, p, td, table, tr, .bodytext, .stepfield { + font-family: Verdana, arial, sans-serif; + font-size: 11px; + line-height: 16px; + color: #000000; + font-weight: normal; +} +#PageContent { + text-align: left; + background-color: #fff; + padding: 0px; + margin: 0px; + padding-bottom:20px; +} +/* +** when this stylesheet is used for the Tiny MCE Wysiwyg editor's edit area, we can't +** use an id=PageContent or class=wiki-content, so we must +** set the body style to that used for PageContent, and p to that used for wiki-content. +*/ + +body { + margin: 0px; + padding: 0px; + text-align: center; + background-color: #f0f0f0; +} + +@media print { + +body { + background-color: #fff; +} + +} + +.monospaceInput { + font:12px monospace +} + +.wiki-content p, .commentblock p { + margin: 16px 0px 16px 0px; + padding: 0px; +} + +.wiki-content-preview { + padding: 5px; + border-left: 1px solid #3c78b5; + border-right: 1px solid #3c78b5; +} + +ul, ol { + margin-top: 2px; + margin-bottom: 2px; + padding-top: 0px; + padding-bottom: 0px; +} + +pre { + padding: 0px; + margin-top: 5px; + margin-left: 15px; + margin-bottom: 5px; + margin-right: 5px; + text-align: left; +} + +.helpheading { + font-weight: bold; + background-color: #D0D9BD; + border-bottom: 1px solid #3c78b5; + padding: 4px 4px 4px 4px; + margin: 0px; + margin-top: 10px; +} +.helpcontent { + padding: 4px 4px 20px 4px; + background-color: #f5f7f1; +} + +.code { + border: 1px dashed #3c78b5; + font-size: 11px; + font-family: Courier; + margin: 10px; + line-height: 13px; +} + +.focusedComment { + background: #ffffce; +} + +.commentBox, .focusedComment { + padding: 10px; + margin: 5px 0 5px 0; + border: 1px #bbb solid; +} + +.codeHeader { + background-color: #f0f0f0; + border-bottom: 1px dashed #3c78b5; + padding: 3px; + text-align: center; +} + +.codeContent { + text-align: left; + background-color: #f0f0f0; + padding: 3px; +} + +.preformatted { + border: 1px dashed #3c78b5; + font-size: 11px; + font-family: Courier; + margin: 10px; + line-height: 13px; +} + +.preformattedHeader { + background-color: #f0f0f0; + border-bottom: 1px dashed #3c78b5; + padding: 3px; + text-align: center; +} + +.preformattedContent { + background-color: #f0f0f0; + padding: 3px; +} + +.panel { + border: 1px dashed #3c78b5; + margin: 10px; + margin-top: 0px; +} + +.panelHeader { + background-color: #f0f0f0; + border-bottom: 1px dashed #3c78b5; + padding: 3px; + text-align: center; +} + +.panelContent { + background-color: #f0f0f0; + padding: 5px; +} + +.anonymousAlert { + background-color: #f0f0f0; + border: 1px dashed red; + font-size: 11px; + padding: 10px 5px 10px 5px; + margin: 4px; + line-height: 13px; +} + +.lockAlert { + background-color: #f0f0f0; + width: 50%; + border: 1px dashed red; + font-size: 11px; + padding: 10px 5px 10px 5px; + margin: 4px; + line-height: 13px; +} + + +.code-keyword { + color: #000091; + background-color: inherit; +} + +.code-object { + color: #910091; + background-color: inherit; +} + +.code-quote { + color: #009100; + background-color: inherit; +} + +.code-comment { + color: #808080; + background-color: inherit; +} + + +.code-xml .code-keyword { + color: inherit; + font-weight: bold; +} + +.code-tag { + color: #000091; + background-color: inherit; +} + +.breadcrumbs { + background-color: #f0f0f0; + border-color: #3c78b5; + border-width: 1px 0px 1px 0px; + border-style: solid; + font-size: 11px; + padding: 3px 0px 3px 0px; +} + +.navmenu { + border: 1px solid #ccc; +} + +.menuheading { + font-weight: bold; + background-color: #f0f0f0; + border-bottom: 1px solid #3c78b5; + padding: 4px 4px 2px 4px; +} + +.menuitems { + padding: 4px 4px 20px 4px; +} + +.rightpanel { + border-left: 1px solid #ccc; + border-bottom: 1px solid #ccc; +} + +#helpheading { + text-align: left; + font-weight: bold; + background-color: #D0D9BD; + border-bottom: 1px solid #3c78b5; + padding: 4px 4px 4px 4px; + margin: 0px; +} +#helpcontent { + padding: 4px 4px 4px 4px; + background-color: #f5f7f1; +} +.helptab-unselected { + font-weight: bold; + padding: 5px; + background-color: #f5f7f1; +} +.helptab-selected { + font-weight: bold; + background-color: #D0D9BD; + padding: 5px; +} +.helptabs { + margin: 0px; + background-color: #f5f7f1; + padding: 5px; +} +.infopanel-heading { + font-weight: bold; + padding: 4px 0px 2px 0px; +} + +.pagebody { +} + +.pageheader { + padding: 5px 5px 5px 0px; + border-bottom: 1px solid #3c78b5; +} + +.pagetitle { + font-size: 22px; + font-weight: bold; + font-family: Arial, sans-serif; + color: #003366; +} + +.newpagetitle { + color: #ccc !important; +} + +.steptitle { + font-size: 18px; + font-weight: bold; + font-family: Arial, sans-serif; + color: #003366; + margin-bottom: 7px; +} + +.substeptitle { + font-size: 12px; + font-weight: bold; + font-family: Arial, sans-serif; + color: #003366; + margin: 2px 4px 4px 4px; + padding: 2px 4px 1px 4px; +} + +.stepdesc { + font-family: Verdana, arial, sans-serif; + font-size: 11px; + line-height: 16px; + font-weight: normal; + color: #666666; + margin-top: 7px; + margin-bottom: 7px; +} + +.steplabel { + font-weight: bold; + margin-right: 4px; + color: black; + float: left; + width: 15%; + text-align: right; +} + +.stepfield { + background: #f0f0f0; + padding: 5px; +} + +.submitButtons{ + margin-top:5px; + text-align:right; +} + +.formtitle { + font-size: 12px; + font-weight: bold; + font-family: Arial, sans-serif; + color: #003366; +} + +.sectionbottom { + border-bottom: 1px solid #3c78b5; +} + +.topRow { + border-top: 2px solid #3c78b5; +} + +.tabletitle { + font-size: 14px; + font-weight: bold; + font-family: Arial, sans-serif; + padding: 3px 0px 2px 0px; + margin: 8px 4px 2px 0px; + color: #003366; + border-bottom: 2px solid #3c78b5; +} +.pagesubheading { + color: #666666; + font-size: 10px; + padding: 0px 0px 5px 0px; +} + +HR { + color: 3c78b5; + height: 1; +} + +A:link, A:visited, A:active, A:hover { + color: #003366; +} + +h1 A:link, h1 A:visited, h1 A:active { + text-decoration: none; +} + +h1 A:hover { + border-bottom: 1px dotted #003366; +} + +.wiki-content > :first-child, .commentblock > :first-child { + margin-top: 3px; +} + +.logocell { + padding: 10px; +} + +input { + font-family: verdana, geneva, arial, sans-serif; + font-size: 11px; + color: #000000; +} + +textarea, textarea.editor { + font-family: verdana, geneva, arial, sans-serif; + font-size: 11px; + color: #333333; +} + +/* use logoSpaceLink instead. +.spacenametitle { + font: 21px/31px Impact, Arial, Helvetica; + font-weight: 100; + color: #999999; + margin: 0px; +} +.spacenametitle img { + margin: 0 0 -4px 0; +} +.spacenametitle a { + text-decoration: none; + color: #999999; +} +.spacenametitle a:visited { + text-decoration: none; + color: #999999; +}*/ + +.spacenametitle-printable { + font: 20px/25px Impact, Arial, Helvetica; + font-weight: 100; + color: #999999; + margin: 0px; +} +.spacenametitle-printable a { + text-decoration: none; + color: #999999; +} +.spacenametitle-printable a:visited { + text-decoration: none; + color: #999999; +} + +.blogDate { + font-weight: bold; + text-decoration: none; + color: black; +} + +.blogSurtitle { + background: #f0f0f0; + border: 1px solid #ddd; + padding: 3px; + margin: 1px 1px 10px 1px; +} + +.blogHeading { + font-size: 20px; + line-height: normal; + font-weight: bold; + padding: 0px; + margin: 0px; +} + +.blogHeading a { + text-decoration: none; + color: black; +} + +.endsection { + align: right; + color: #666666; + margin-top: 10px; +} +.endsectionleftnav { + align: right; + color: #666666; + margin-top: 10px; +} + +h1 { + font-size: 24px; + line-height: normal; + font-weight: bold; + background-color: #f0f0f0; + color: #003366; + border-bottom: 1px solid #3c78b5; + padding: 2px; + margin: 36px 0px 4px 0px; +} + +h2 { + font-size: 18px; + line-height: normal; + font-weight: bold; + background-color: #f0f0f0; + border-bottom: 1px solid #3c78b5; + padding: 2px; + margin: 27px 0px 4px 0px; +} + +h3 { + font-size: 14px; + line-height: normal; + font-weight: bold; + background-color: #f0f0f0; + padding: 2px; + margin: 21px 0px 4px 0px; +} + +h4 { + font-size: 12px; + line-height: normal; + font-weight: bold; + background-color: #f0f0f0; + padding: 2px; + margin: 18px 0px 4px 0px; +} + +h4.search { + font-size: 12px; + line-height: normal; + font-weight: normal; + background-color: #f0f0f0; + padding: 4px; + margin: 18px 0px 4px 0px; +} + +h5 { + font-size: 10px; + line-height: normal; + font-weight: bold; + background-color: #f0f0f0; + padding: 2px; + margin: 14px 0px 4px 0px; +} + +h6 { + font-size: 8px; + line-height: normal; + font-weight: bold; + background-color: #f0f0f0; + padding: 2px; + margin: 14px 0px 4px 0px; +} + +.smallfont { + font-size: 10px; +} +.descfont { + font-size: 10px; + color: #666666; +} +.smallerfont { + font-size: 9px; +} +.smalltext { + color: #666666; + font-size: 10px; +} +.smalltext a { + color: #666666; +} +.smalltext-blue { + color: #3c78b5; + font-size: 10px; +} +.surtitle { + margin-left: 1px; + margin-bottom: 5px; + font-size: 14px; + color: #666666; +} + +/* css hack found here: http://www.fo3nix.pwp.blueyonder.co.uk/tutorials/css/hacks/ */ +.navItemOver { font-size: 10px; font-weight: bold; color: #ffffff; background-color: #003366; cursor: hand; voice-family: '\'}\''; voice-family:inherit; cursor: pointer;} +.navItemOver a { color: #ffffff; background-color:#003366; text-decoration: none; } +.navItemOver a:visited { color: #ffffff; background-color:#003366; text-decoration: none; } +.navItemOver a:hover { color: #ffffff; background-color:#003366; text-decoration: none; } +.navItem { font-size: 10px; font-weight: bold; color: #ffffff; background-color: #3c78b5; } +.navItem a { color: #ffffff; text-decoration: none; } +.navItem a:hover { color: #ffffff; text-decoration: none; } +.navItem a:visited { color: #ffffff; text-decoration: none; } + +div.padded { padding: 4px; } +div.thickPadded { padding: 10px; } +h3.macrolibrariestitle { + margin: 0px 0px 0px 0px; +} + +div.centered { text-align: center; margin: 10px; } +div.centered table {margin: 0px auto; text-align: left; } + +.tableview table { + margin: 0; +} + +.tableview th { + text-align: left; + color: #003366; + font-size: 12px; + padding: 5px 0px 0px 5px; + border-bottom: 2px solid #3c78b5; +} +.tableview td { + text-align: left; + border-color: #ccc; + border-width: 0px 0px 1px 0px; + border-style: solid; + margin: 0; + padding: 4px 10px 4px 5px; +} + +.grid { + margin: 2px 0px 5px 0px; + border-collapse: collapse; +} +.grid th { + border: 1px solid #ccc; + padding: 2px 4px 2px 4px; + background: #f0f0f0; + text-align: center; +} +.grid td { + border: 1px solid #ccc; + padding: 3px 4px 3px 4px; +} +.gridHover { + background-color: #f9f9f9; +} + +td.infocell { + background-color: #f0f0f0; +} +.label { + font-weight: bold; + color: #003366; +} + +label { + font-weight: bold; + color: #003366; +} + +.error { + background-color: #fcc; +} + +.errorBox { + background-color: #fcc; + border: 1px solid #c00; + padding: 5px; + margin: 5px; +} + +.errorMessage { + color: #c00; +} + +.success { + background-color: #dfd; +} + +.successBox { + background-color: #dfd; + border: 1px solid #090; + padding: 5px; + margin-top:5px; + margin-bottom:5px; +} + +blockquote { + padding-left: 10px; + padding-right: 10px; + margin-left: 5px; + margin-right: 0px; + border-left: 1px solid #3c78b5; +} + +table.confluenceTable +{ + margin: 5px; + border-collapse: collapse; +} + +/* Added as a temporary fix for CONF-4223. The table elements appear to be inheriting the border: none attribute from the sectionMacro class */ +table.confluenceTable td.confluenceTd +{ + border-width: 1px; + border-style: solid; + border-color: #ccc; + padding: 3px 4px 3px 4px; +} + +/* Added as a temporary fix for CONF-4223. The table elements appear to be inheriting the border: none attribute from the sectionMacro class */ +table.confluenceTable th.confluenceTh +{ + border-width: 1px; + border-style: solid; + border-color: #ccc; + padding: 3px 4px 3px 4px; + background-color: #f0f0f0; + text-align: center; +} + +td.confluenceTd +{ + border-width: 1px; + border-style: solid; + border-color: #ccc; + padding: 3px 4px 3px 4px; +} + +th.confluenceTh +{ + border-width: 1px; + border-style: solid; + border-color: #ccc; + padding: 3px 4px 3px 4px; + background-color: #f0f0f0; + text-align: center; +} + +DIV.small { + font-size: 9px; +} + +H1.pagename { + margin-top: 0px; +} + +IMG.inline {} + +.loginform { + margin: 5px; + border: 1px solid #ccc; +} + +/* The text how the "This is a preview" comment should be shown. */ +.previewnote { text-align: center; + font-size: 11px; + color: red; } + +/* How the preview content should be shown */ +.previewcontent { background: #E0E0E0; } + +/* How the system messages should be shown (DisplayMessage.jsp) */ +.messagecontent { background: #E0E0E0; } + +/* How the "This page has been modified..." -comment should be shown. */ +.conflictnote { } + +.createlink { + color: maroon; +} +a.createlink { + color: maroon; +} +.templateparameter { + font-size: 9px; + color: darkblue; +} + +.diffadded { + background: #ddffdd; + padding: 1px 1px 1px 4px; + border-left: 4px solid darkgreen; +} +.diffdeleted { + color: #999; + background: #ffdddd; + padding: 1px 1px 1px 4px; + border-left: 4px solid darkred; +} +.diffnochange { + padding: 1px 1px 1px 4px; + border-left: 4px solid lightgrey; +} +.differror { + background: brown; +} +.diff { + font-family: lucida console, courier new, fixed-width; + font-size: 12px; + line-height: 14px; +} +.diffaddedchars { + background-color:#99ff99; + font-weight:bolder; +} +.diffremovedchars { + background-color:#ff9999; + text-decoration: line-through; + font-weight:bolder; +} + +.greybackground { + background: #f0f0f0 +} + +.greybox { + border: 1px solid #ddd; + padding: 3px; + margin: 1px 1px 10px 1px; +} + +.borderedGreyBox { + border: 1px solid #cccccc; + background-color: #f0f0f0; + padding: 10px; +} + +.greyboxfilled { + border: 1px solid #ddd; + background: #f0f0f0; + padding: 3px; + margin: 1px 1px 10px 1px; +} + +.navBackgroundBox { + padding: 5px 5px 5px 5px; + font-size: 22px; + font-weight: bold; + font-family: Arial, sans-serif; + color: white; + background: #3c78b5; + text-decoration: none; +} + +.previewBoxTop { + background-color: #f0f0f0; + border-width: 1px 1px 0px 1px; + border-style: solid; + border-color: #3c78b5; + padding: 5px; + margin: 5px 0px 0px 0px; + text-align: center; +} +.previewContent { + background-color: #fff; + border-color: #3c78b5; + border-width: 0px 1px 0px 1px; + border-style: solid; + padding: 10px; + margin: 0px; +} +.previewBoxBottom { + background-color: #f0f0f0; + border-width: 0px 1px 1px 1px; + border-style: solid; + border-color: #3c78b5; + padding: 5px; + margin: 0px 0px 5px 0px; + text-align: center; +} + +.functionbox { + background-color: #f0f0f0; + border: 1px solid #3c78b5; + padding: 3px; + margin: 1px 1px 10px 1px; +} + +.functionbox-greyborder { + background-color: #f0f0f0; + border: 1px solid #ddd; + padding: 3px; + margin: 1px 1px 10px 1px; +} + +.search-highlight { + background-color: #ffffcc; +} + +/* normal (white) background */ +.rowNormal { + background-color: #ffffff; + } + +/* alternate (pale yellow) background */ +.rowAlternate { + background-color: #f7f7f7; +} + +/* used in the list attachments table */ +.rowAlternateNoBottomColor { + background-color: #f7f7f7; +} + +.rowAlternateNoBottomNoColor { +} + +.rowAlternateNoBottomColor td { + border-bottom: 0px; +} + +.rowAlternateNoBottomNoColor td { + border-bottom: 0px; +} + +/* row highlight (grey) background */ +.rowHighlight { + background-color: #f0f0f0; + +} + +TD.greenbar {FONT-SIZE: 2px; BACKGROUND: #00df00; BORDER: 1px solid #9c9c9c; PADDING: 0px; } +TD.redbar {FONT-SIZE: 2px; BACKGROUND: #df0000; BORDER: 1px solid #9c9c9c; PADDING: 0px; } +TD.darkredbar {FONT-SIZE: 2px; BACKGROUND: #af0000; BORDER: 1px solid #9c9c9c; PADDING: 0px; } + +TR.testpassed {FONT-SIZE: 2px; BACKGROUND: #ddffdd; PADDING: 0px; } +TR.testfailed {FONT-SIZE: 2px; BACKGROUND: #ffdddd; PADDING: 0px; } + +.toolbar { + margin: 0px; + border-collapse: collapse; +} + +.toolbar td { + border: 1px solid #ccc; + padding: 2px 2px 2px 2px; + color: #ccc; +} + +td.noformatting { + border-width: 0px; + border-style: none; + text-align: center; + padding: 0px; +} + +.commentblock { + margin: 12px 0 12px 0; +} + +/* + * Divs displaying the license information, if necessary. + */ +.license-eval, .license-none, .license-nonprofit { + border-top: 1px solid #bbbbbb; + text-align: center; + font-size: 10px; + font-family: Verdana, Arial, Helvetica, sans-serif; +} + +.license-eval, .license-none { + background-color: #ffcccc; +} + +.license-eval b, .license-none b { + color: #990000 +} + +.license-nonprofit { + background-color: #ffffff; +} + +/* + * The shadow at the bottom of the page between the main content and the + * "powered by" section. + */ +.bottomshadow { + height: 12px; + background-image: url("$req.contextPath/images/border/border_bottom.gif"); + background-repeat: repeat-x; +} + +/* + * Styling of the operations box + */ +.navmenu .operations li, .navmenu .operations ul { + list-style: none; + margin-left: 0; + padding-left: 0; +} + +.navmenu .operations ul { + margin-bottom: 9px; +} + +.navmenu .label { + font-weight: inherit; +} + +/* + * Styling of ops as a toolbar + */ +.toolbar div { + display: none; +} + +.toolbar .label { + display: none; +} + +.toolbar .operations { + display: block; +} + +.toolbar .operations ul { + display: inline; + list-style: none; + margin-left: 10px; + padding-left: 0; +} + +.toolbar .operations li { + list-style: none; + display: inline; +} + +/* list page navigational tabs */ +#foldertab { +padding: 3px 0px 3px 8px; +margin-left: 0; +border-bottom: 1px solid #3c78b5; +font: bold 11px Verdana, sans-serif; +} + +#foldertab li { +list-style: none; +margin: 0; +display: inline; +} + +#foldertab li a { +padding: 3px 0.5em; +margin-left: 3px; +border: 1px solid #3c78b5; +border-bottom: none; +background: #3c78b5; +text-decoration: none; +} + +#foldertab li a:link { color: #ffffff; } +#foldertab li a:visited { color: #ffffff; } + +#foldertab li a:hover { +color: #ffffff; +background: #003366; +border-color: #003366; +} + +#foldertab li a.current { +background: white; +border-bottom: 1px solid white; +color: black; +} + +#foldertab li a.current:link { color: black; } +#foldertab li a.current:visited { color: black; } +#foldertab li a.current:hover { +background: white; +border-bottom: 1px solid white; +color: black; +} + +/* alphabet list */ +ul#squaretab { +margin-left: 0; +padding-left: 0; +white-space: nowrap; +font: bold 8px Verdana, sans-serif; +} + +#squaretab li { +display: inline; +list-style-type: none; +} + +#squaretab a { +padding: 2px 6px; +border: 1px solid #3c78b5; +} + +#squaretab a:link, #squaretab a:visited { +color: #fff; +background-color: #3c78b5; +text-decoration: none; +} + +#squaretab a:hover { +color: #ffffff; +background-color: #003366; +border-color: #003366; +text-decoration: none; +} + +#squaretab li a#current { +background: white; +color: black; +} + +.blogcalendar * { + font-family:verdana, arial, sans-serif; + font-size:x-small; + font-weight:normal; + line-height:140%; + padding:2px; +} + + +table.blogcalendar { + border: 1px solid #3c78b5; +} + +.blogcalendar th.calendarhead, a.calendarhead { + font-size:x-small; + font-weight:bold; + padding:2px; + text-transform:uppercase; + background-color: #3c78b5; + color: #ffffff; + letter-spacing: .3em; + text-transform: uppercase; +} + +.calendarhead:visited {color: white;} +.calendarhead:active {color: white;} +.calendarhead:hover {color: white;} + +.blogcalendar th { + font-size:x-small; + font-weight:bold; + padding:2px; + background-color:#f0f0f0; +} + +.blogcalendar td { + font-size:x-small; + font-weight:normal; +} + +.searchGroup { padding: 0 0 10px 0; background: #f0f0f0; } +.searchGroupHeading { font-size: 10px; font-weight: bold; color: #ffffff; background-color: #3c78b5; padding: 2px 4px 1px 4px; } +.searchItem { padding: 1px 4px 1px 4px; } +.searchItemSelected { padding: 1px 4px 1px 4px; font-weight: bold; background: #ddd; } + +/* permissions page styles */ +.permissionHeading { + border-bottom: #bbb; border-width: 0 0 1px 0; border-style: solid; font-size: 16px; text-align: left; +} +.permissionTab { + border-width: 0 0 0 1px; border-style: solid; background: #3c78b5; color: #ffffff; font-size: 10px; +} +.permissionSuperTab { + border-width: 0 0 0 1px; border-style: solid; background: #003366; color: #ffffff; +} +.permissionCell { + border-left: #bbb; border-width: 0 0 0 1px; border-style: solid; +} + +/* warning panel */ +.warningPanel { background: #FFFFCE; border:#F0C000 1px solid; padding: 8px; margin: 10px; } +/* alert panel */ +.alertPanel { background: #FFCCCC; border:#C00 1px solid; padding: 8px; margin: 10px; } +/* info panel */ +.infoPanel { background: #D8E4F1; border:#3c78b5 1px solid; padding: 8px; margin: 10px; } + +/* side menu highlighting (e.g. space content screen) */ +.optionPadded { padding: 2px; } +.optionSelected { background-color: #ffffcc; padding: 2px; border: 1px solid #ddd; margin: -1px; } +.optionSelected a { font-weight: bold; text-decoration: none; color: black; } + +/* information macros */ +.noteMacro { border-style: solid; border-width: 1px; border-color: #F0C000; background-color: #FFFFCE; text-align:left; margin-top: 5px; margin-bottom: 5px} +.warningMacro { border-style: solid; border-width: 1px; border-color: #c00; background-color: #fcc; text-align:left; margin-top: 5px; margin-bottom: 5px} +.infoMacro { border-style: solid; border-width: 1px; border-color: #3c78b5; background-color: #D8E4F1; text-align:left; margin-top: 5px; margin-bottom: 5px} +.tipMacro { border-style: solid; border-width: 1px; border-color: #090; background-color: #dfd; text-align:left; margin-top: 5px; margin-bottom: 5px} +.informationMacroPadding { padding: 5px 0 0 5px; } + +table.infoMacro td, table.warningMacro td, table.tipMacro td, table.noteMacro td, table.sectionMacro td { + border: none; +} + +table.sectionMacroWithBorder td.columnMacro { border-style: dashed; border-width: 1px; border-color: #cccccc;} + +.pagecontent +{ + padding: 10px; + text-align: left; +} + +/* styles for links in the top bar */ +.topBarDiv a:link {color: #ffffff;} +.topBarDiv a:visited {color: #ffffff;} +.topBarDiv a:active {color: #ffffff;} +.topBarDiv a:hover {color: #ffffff;} +.topBarDiv {color: #ffffff;} + +.topBar { + background-color: #003366; +} + + +/* styles for extended operations */ +.greyLinks a:link {color: #666666; text-decoration:underline;} +.greyLinks a:visited {color: #666666; text-decoration:underline;} +.greyLinks a:active {color: #666666; text-decoration:underline;} +.greyLinks a:hover {color: #666666; text-decoration:underline;} +.greyLinks {color: #666666; display:block; padding: 10px} + +.logoSpaceLink {color: #999999; text-decoration: none} +.logoSpaceLink a:link {color: #999999; text-decoration: none} +.logoSpaceLink a:visited {color: #999999; text-decoration: none} +.logoSpaceLink a:active {color: #999999; text-decoration: none} +.logoSpaceLink a:hover {color: #003366; text-decoration: none} + +/* basic panel (basicpanel.vmd) style */ +.basicPanelContainer {border: 1px solid #3c78b5; margin-top: 2px; margin-bottom: 8px; width: 100%} +.basicPanelTitle {padding: 5px; margin: 0px; background-color: #f0f0f0; color: black; font-weight: bold;} +.basicPanelBody {padding: 5px; margin: 0px} + +.separatorLinks a:link {color: white} +.separatorLinks a:visited {color: white} +.separatorLinks a:active {color: white} + +.greynavbar {background-color: #f0f0f0; border-top: 1px solid #3c78b5; margin-top: 2px} + +div.headerField { + float: left; + width: auto; + height: 100%; +} + +.headerFloat { + margin-left: auto; + width: 50%; +} + +.headerFloatLeft { + float: left; + margin-right: 20px; + margin-bottom: 10px; +} + +#headerRow { + padding: 10px; +} + +div.license-personal { + background-color: #003366; + color: #ffffff; +} + +div.license-personal a { + color: #ffffff; +} + +.greyFormBox { + border: 1px solid #cccccc; + padding: 5px; +} + +/* IE automatically adds a margin before and after form tags. Use this style to remove that */ +.marginlessForm { + margin: 0px; +} + +.openPageHighlight { + background-color: #ffffcc; + padding: 2px; + border: 1px solid #ddd; +} + +.editPageInsertLinks, .editPageInsertLinks a +{ + color: #666666; + font-weight: bold; + font-size: 10px; +} + +/* Style for label heatmap. */ +.top10 a { + font-weight: bold; + font-size: 2em; + color: #003366; +} +.top25 a { + font-weight: bold; + font-size: 1.6em; + color: #003366; +} +.top50 a { + font-size: 1.4em; + color: #003366; +} +.top100 a { + font-size: 1.2em; + color: #003366; +} + +.heatmap { + list-style:none; + width: 95%; + margin: 0px auto; +} + +.heatmap a { + text-decoration:none; +} + +.heatmap a:hover { + text-decoration:underline; +} + +.heatmap li { + display: inline; +} + +.minitab { +padding: 3px 0px 3px 8px; +margin-left: 0; +margin-top: 1px; +margin-bottom: 0px; +border-bottom: 1px solid #3c78b5; +font: bold 9px Verdana, sans-serif; +text-decoration: none; +float:none; +} +.selectedminitab { +padding: 3px 0.5em; +margin-left: 3px; +margin-top: 1px; +border: 1px solid #3c78b5; +background: white; +border-bottom: 1px solid white; +color: #000000; +text-decoration: none; +} +.unselectedminitab { +padding: 3px 0.5em; +margin-left: 3px; +margin-top: 1px; +border: 1px solid #3c78b5; +border-bottom: none; +background: #3c78b5; +color: #ffffff; +text-decoration: none; +} + +a.unselectedminitab:hover { +color: #ffffff; +background: #003366; +border-color: #003366; +} + +a.unselectedminitab:link { color: white; } +a.unselectedminitab:visited { color: white; } + +a.selectedminitab:link { color: black; } +a.selectedminitab:visited { color: black; } + +.linkerror { background-color: #fcc;} + +a.labelOperationLink:link {text-decoration: underline} +a.labelOperationLink:active {text-decoration: underline} +a.labelOperationLink:visited {text-decoration: underline} +a.labelOperationLink:hover {text-decoration: underline} + +a.newLabel:link {background-color: #ddffdd} +a.newLabel:active {background-color: #ddffdd} +a.newLabel:visited {background-color: #ddffdd} +a.newLabel:hover {background-color: #ddffdd} + +ul.square {list-style-type: square} + +.inline-control-link { + background: #ffc; + font-size: 9px; + color: #666; + padding: 2px; + text-transform: uppercase; + text-decoration: none; +} + + +.inline-control-link a:link {text-decoration: none} +.inline-control-link a:active {text-decoration: none} +.inline-control-link a:visited {text-decoration: none} +.inline-control-link a:hover {text-decoration: none} + +.inline-control-link { + background: #ffc; + font-size: 9px; + color: #666; + padding: 2px; + text-transform: uppercase; + text-decoration: none; + cursor: pointer; +} + +div.auto_complete { + width: 350px; + background: #fff; +} +div.auto_complete ul { + border: 1px solid #888; + margin: 0; + padding: 0; + width: 100%; + list-style-type: none; +} +div.auto_complete ul li { + margin: 0; + padding: 3px; +} +div.auto_complete ul li.selected { + background-color: #ffb; +} +div.auto_complete ul strong.highlight { + color: #800; + margin: 0; + padding: 0; +} + +/******* Edit Page Styles *******/ +.toogleFormDiv{ + border:1px solid #A7A6AA; + background-color:white; + padding:5px; + margin-top: 5px; +} + +.toogleInfoDiv{ + border:1px solid #A7A6AA; + background-color:white; + display:none; + padding:5px; + margin-top: 10px; +} + +.inputSection{ + margin-bottom:20px; +} + +#editBox{ + border:1px solid lightgray; + background-color:#F0F0F0; +} + +/******* Left Navigation Theme Styles ********/ +.leftnav li a { + text-decoration:none; + color:white; + margin:0px; + display:block; + padding:2px; + padding-left:5px; + background-color: #3c78b5; + border-top:1px solid #3c78b5; +} + +.leftnav li a:active {color:white;} +.leftnav li a:visited {color:white;} +.leftnav li a:hover {background-color: #003366; color:white;} + +/* Added by Shaun during i18n */ +.replaced +{ + background-color: #33CC66; +} + +.topPadding +{ + margin-top: 20px; +} + +/* new form style */ +.form-block { + padding: 6px; +} +.form-error-block { + padding: 6px; + background: #fcc; + border-top: #f0f0f0 1px solid; + border-bottom: #f0f0f0 1px solid; + margin-bottom: 6px; + padding: 0 12px 0 12px; +} +.form-element-large { + font-size: 16px; + font-weight: bold; + font-family: Arial, sans-serif; + color: #003366; +} + +.form-element-small { + font-size: 12px; + font-weight: bold; + font-family: Arial, sans-serif; + color: #003366; +} + +.form-header { + background: lightyellow; + border-top: #f0f0f0 1px solid; + border-bottom: #f0f0f0 1px solid; + margin-bottom: 6px; + padding: 0 12px 0 12px; +} +.form-header p, .form-block p, .form-error-block p { + line-height: normal; + margin: 12px 0 12px 0; +} +.form-example { + color: #888; + font-size: 11px; +} +.form-divider { + border-bottom: #ccc 1px solid; + margin-bottom: 6px; +} +.form-buttons { + margin-top: 6px; + border-top: #ccc 1px solid; + border-bottom: #ccc 1px solid; + background: #f0f0f0; + padding: 10px; + text-align: center; +} +.form-buttons input { + width: 100px; +} +.form-block .error { + padding: 6px; + margin-bottom: 6px; +} \ No newline at end of file diff --git a/documentation/content/xdocs/tabs.xml b/documentation/content/xdocs/tabs.xml new file mode 100755 index 0000000000..dfbf4bc891 --- /dev/null +++ b/documentation/content/xdocs/tabs.xml @@ -0,0 +1,36 @@ + + + + + + + + + diff --git a/documentation/resources/images/ellipse-2.svg b/documentation/resources/images/ellipse-2.svg new file mode 100755 index 0000000000..32df27eb79 --- /dev/null +++ b/documentation/resources/images/ellipse-2.svg @@ -0,0 +1,30 @@ + + + + + Ellipse + + + diff --git a/documentation/resources/images/icon-a.png b/documentation/resources/images/icon-a.png new file mode 100755 index 0000000000..64e66358b0 Binary files /dev/null and b/documentation/resources/images/icon-a.png differ diff --git a/documentation/resources/images/icon-b.png b/documentation/resources/images/icon-b.png new file mode 100755 index 0000000000..b0c0db3689 Binary files /dev/null and b/documentation/resources/images/icon-b.png differ diff --git a/documentation/resources/images/icon.png b/documentation/resources/images/icon.png new file mode 100755 index 0000000000..3be8bbbe65 Binary files /dev/null and b/documentation/resources/images/icon.png differ diff --git a/documentation/resources/images/project-logo.png b/documentation/resources/images/project-logo.png new file mode 100755 index 0000000000..8a63e42038 Binary files /dev/null and b/documentation/resources/images/project-logo.png differ diff --git a/documentation/resources/images/sub-dir/icon-c.png b/documentation/resources/images/sub-dir/icon-c.png new file mode 100755 index 0000000000..c3a2644ccd Binary files /dev/null and b/documentation/resources/images/sub-dir/icon-c.png differ diff --git a/documentation/resources/schema/catalog.xcat b/documentation/resources/schema/catalog.xcat new file mode 100755 index 0000000000..b32ce37fcb --- /dev/null +++ b/documentation/resources/schema/catalog.xcat @@ -0,0 +1,29 @@ + + + + + + + + + + diff --git a/documentation/resources/schema/hello-v10.dtd b/documentation/resources/schema/hello-v10.dtd new file mode 100755 index 0000000000..43b4c863ec --- /dev/null +++ b/documentation/resources/schema/hello-v10.dtd @@ -0,0 +1,51 @@ + + + + + + + + + + + + diff --git a/documentation/resources/schema/symbols-project-v10.ent b/documentation/resources/schema/symbols-project-v10.ent new file mode 100755 index 0000000000..33a9bf441b --- /dev/null +++ b/documentation/resources/schema/symbols-project-v10.ent @@ -0,0 +1,26 @@ + + + + +My Project Name"> + diff --git a/documentation/resources/stylesheets/hello2document.xsl b/documentation/resources/stylesheets/hello2document.xsl new file mode 100755 index 0000000000..50d20174ae --- /dev/null +++ b/documentation/resources/stylesheets/hello2document.xsl @@ -0,0 +1,33 @@ + + + + + + +
+ <xsl:value-of select="greeting"/> +
+ + + + + + diff --git a/documentation/sitemap.xmap b/documentation/sitemap.xmap new file mode 100755 index 0000000000..ca7a5353da --- /dev/null +++ b/documentation/sitemap.xmap @@ -0,0 +1,66 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/documentation/skinconf.xml b/documentation/skinconf.xml new file mode 100755 index 0000000000..117effbd5e --- /dev/null +++ b/documentation/skinconf.xml @@ -0,0 +1,416 @@ + + + + + + + + + true + + false + + true + + true + + + true + + true + + false + + true + .at. + + true + + MyProject + MyProject Description + http://myproj.mygroup.org/ + images/project.png + + + MyGroup + MyGroup Description + http://mygroup.org + images/group.png + + + + + + + + false + + 2005 + The Example Organisation. + + http://www.example.org/ + + + + + + + + + + + + + Send feedback about the website to: + + + + + sample + + This is an example of a Message of the day (MOTD). + + faq.html + + + + How to enable this MOTD is on this page. + + http://forrest.apache.org/docs/faq.html + + + + + + p.quote { + margin-left: 2em; + padding: .5em; + background-color: #f0f0f0; + font-family: monospace; + } + + #footer a { color: #0F3660; } + #footer a:visited { color: #009999; } + + + + + + + + + + + + + + + + + + Page 1 + + + 1in + 1in + 1.25in + 1in + + + false + + false + + + + + Built with Apache Forrest + http://forrest.apache.org/ + images/built-with-forrest-button.png + 88 + 31 + + + + + diff --git a/documentation/translations/langcode.xml b/documentation/translations/langcode.xml new file mode 100755 index 0000000000..b11b3400d2 --- /dev/null +++ b/documentation/translations/langcode.xml @@ -0,0 +1,29 @@ + + + + + English + Espanol + Italiano + Nederlands + Deutsch + Francais + diff --git a/documentation/translations/languages_de.xml b/documentation/translations/languages_de.xml new file mode 100755 index 0000000000..17901714d2 --- /dev/null +++ b/documentation/translations/languages_de.xml @@ -0,0 +1,24 @@ + + + + Englisch + Spanisch + Holländisch + Deutsch + Französisch + diff --git a/documentation/translations/languages_en.xml b/documentation/translations/languages_en.xml new file mode 100644 index 0000000000..9fb1ae7656 --- /dev/null +++ b/documentation/translations/languages_en.xml @@ -0,0 +1,24 @@ + + + + English + Spanish + Dutch + German + French + diff --git a/documentation/translations/languages_es.xml b/documentation/translations/languages_es.xml new file mode 100755 index 0000000000..e784e2c66f --- /dev/null +++ b/documentation/translations/languages_es.xml @@ -0,0 +1,22 @@ + + + + Inglés + Español + Holandés + diff --git a/documentation/translations/languages_fr.xml b/documentation/translations/languages_fr.xml new file mode 100755 index 0000000000..30bc4efd7b --- /dev/null +++ b/documentation/translations/languages_fr.xml @@ -0,0 +1,24 @@ + + + + Anglais + Espagnol + Néerlandais + Allemand + Français + diff --git a/documentation/translations/languages_nl.xml b/documentation/translations/languages_nl.xml new file mode 100755 index 0000000000..084570668b --- /dev/null +++ b/documentation/translations/languages_nl.xml @@ -0,0 +1,24 @@ + + + + Engels + Spaans + Nederlands + Duits + Frans + diff --git a/documentation/translations/menu.xml b/documentation/translations/menu.xml new file mode 100755 index 0000000000..7d5e504c99 --- /dev/null +++ b/documentation/translations/menu.xml @@ -0,0 +1,33 @@ + + + + About + Index + Changes + Todo + Samples + Apache document + Static content + Linking + Wiki page + Ihtml page + Ehtml page + FAQ + Simplifed Docbook + XSP page + diff --git a/documentation/translations/menu_af.xml b/documentation/translations/menu_af.xml new file mode 100755 index 0000000000..c07a6b68b1 --- /dev/null +++ b/documentation/translations/menu_af.xml @@ -0,0 +1,33 @@ + + + + Aangaande + Inhoud + Veranderinge + Om te doen + Voorbeelde + Apache dokument + Statise Inhoud + Linking + Wiki bladsy + Ihtml bladsy + Ehtml bladsy + FAQ + Vereenvoudigde Docbook + XSP bladsy + diff --git a/documentation/translations/menu_de.xml b/documentation/translations/menu_de.xml new file mode 100755 index 0000000000..237c1f6dc2 --- /dev/null +++ b/documentation/translations/menu_de.xml @@ -0,0 +1,33 @@ + + + + Über + Index + Änderungen + Todo + Beispiele + Apache Dokumentationsseite + Statischer Inhalt + Linking + Wiki Seite + ihtml Seite + ehtml Seite + FAQ + Vereinfachte Docbook + XSP Seite + diff --git a/documentation/translations/menu_es.xml b/documentation/translations/menu_es.xml new file mode 100755 index 0000000000..622048418e --- /dev/null +++ b/documentation/translations/menu_es.xml @@ -0,0 +1,33 @@ + + + + Acerca de + Indice + Cambios + Tareas pendientes + Ejemplos + Documento Apache + Contenido Estático + Linking + Página Wiki + Página ihtml + Página ehtml + Preguntas Frecuentes + Página Simplifed Docbook + Página XSP + diff --git a/documentation/translations/menu_fr.xml b/documentation/translations/menu_fr.xml new file mode 100755 index 0000000000..c318bb591f --- /dev/null +++ b/documentation/translations/menu_fr.xml @@ -0,0 +1,33 @@ + + + + A propos + Index + Modifications + A faire + Exemples + Document Apache + Contenu statique + Gestion des liens + Page wiki + Page ihtml + Page ehtml + FAQ + Docbook simplifié + Page XSP + diff --git a/documentation/translations/menu_it.xml b/documentation/translations/menu_it.xml new file mode 100755 index 0000000000..12e6966e91 --- /dev/null +++ b/documentation/translations/menu_it.xml @@ -0,0 +1,33 @@ + + + + Riguardo a + Indice + Cambiamenti + Cose da fare + Esempi + Apache document + Contenuto Statico + Linking + Pagina Wiki + Pagina ihtml + Pagina ehtml + Domande frequenti + Simplifed Docbook + Pagina XSP + diff --git a/documentation/translations/menu_nl.xml b/documentation/translations/menu_nl.xml new file mode 100755 index 0000000000..19800a2d73 --- /dev/null +++ b/documentation/translations/menu_nl.xml @@ -0,0 +1,33 @@ + + + + Over + Index + Wijzigingen + Nog te doen + Voorbeelden + Apache document + Statische inhoud + Linken + Wiki pagina + Ihtml pagina + Ehtml pagina + FAQ + Vereenvoudigd Docbook + XSP pagina + diff --git a/documentation/translations/menu_no.xml b/documentation/translations/menu_no.xml new file mode 100755 index 0000000000..c091bbace0 --- /dev/null +++ b/documentation/translations/menu_no.xml @@ -0,0 +1,33 @@ + + + + Om + Indeks + Endringer + Oppgave liste + Eksempler + Apache Dokument + Statisk innhold + Linking + Wiki side + ihtml side + ehtml side + FAQ + Simplifed Docbook + XSP side + diff --git a/documentation/translations/menu_ru.xml b/documentation/translations/menu_ru.xml new file mode 100755 index 0000000000..80887e4534 --- /dev/null +++ b/documentation/translations/menu_ru.xml @@ -0,0 +1,33 @@ + + + + О проекте + Содержание + Изменения + План + Примеры + Страница документа Apache + Статическое содержание + Linking + Страница Wiki + Страница ihtml + Страница ehtml + Вопросы/Ответы + Docbook страница + XSP страница + diff --git a/documentation/translations/menu_sk.xml b/documentation/translations/menu_sk.xml new file mode 100755 index 0000000000..4bf7d624f9 --- /dev/null +++ b/documentation/translations/menu_sk.xml @@ -0,0 +1,33 @@ + + + + O programe + Zoznám + Zmeny + Úlohy + Príklady + Apache Document + Statický Obsah + Linking + Wiki stránka + ihtml stránka + ehtml stránka + Casté Otázky + Simplifed Docbook stránka + XSP stránka + diff --git a/documentation/translations/tabs.xml b/documentation/translations/tabs.xml new file mode 100755 index 0000000000..a5e10030a5 --- /dev/null +++ b/documentation/translations/tabs.xml @@ -0,0 +1,22 @@ + + + + Home + Samples + Apache XML Projects + diff --git a/documentation/translations/tabs_de.xml b/documentation/translations/tabs_de.xml new file mode 100755 index 0000000000..19f7d94508 --- /dev/null +++ b/documentation/translations/tabs_de.xml @@ -0,0 +1,22 @@ + + + + Home + Beispiele + Apache XML Projekte + diff --git a/documentation/translations/tabs_es.xml b/documentation/translations/tabs_es.xml new file mode 100755 index 0000000000..d273249151 --- /dev/null +++ b/documentation/translations/tabs_es.xml @@ -0,0 +1,22 @@ + + + + Inicio + Ejemplos + Projectos XML Apache + diff --git a/documentation/translations/tabs_fr.xml b/documentation/translations/tabs_fr.xml new file mode 100755 index 0000000000..73ef5e2395 --- /dev/null +++ b/documentation/translations/tabs_fr.xml @@ -0,0 +1,22 @@ + + + + Accueil + Exemples + Projets Apache XML + diff --git a/documentation/translations/tabs_nl.xml b/documentation/translations/tabs_nl.xml new file mode 100755 index 0000000000..b474c5ca6d --- /dev/null +++ b/documentation/translations/tabs_nl.xml @@ -0,0 +1,22 @@ + + + + Home + Voorbeelden + Apache XML Projecten + -- cgit v1.2.1