We completed profiling of Tuscany 1.6 on Tomcat 6 and JDK 1.6. Would like to perform the same profile testing with 2.x using the travelsample app again on tc6/jdk1.6.
-a- On Mar 14, 2010, at 4:32 PM, "Simon Nash" <[email protected]> wrote: > Simon Laws wrote: >> Haven't looked at the travel sample README for a little while. Anyone >> know how up to date it is? > It should be fully up to date and in sync with the current svn code. > >> For example, the run commands are mostly given as "ant run" but this >> doesn't seem to be the case in the binary distribution. For example, >> from the binary distribution the interaction samples are run using >> "ant run-interaction". So maybe it's just that we need to spell out >> the different types of releases we will have and how to use them. In >> the src distro launchers and contributions will be directories while >> in the bin distro they will be jars. > The "ant run" commands are listed in the section titled "Running the > travel > sample from the build directories" and are correct when running from > the > build directories. For running from the binary distribution, there > is a > later section titled "Running the travel sample from the distribution > directories" which explains the commands needed in this case. Here > is the > paragraph from this section that describes this: > > To run a jar, you need to used the command "ant run-jarsuffix" where > "jarsuffix" is the last part of the jar file name omitting the > standard prefix > "scatours-client", "scatours-launcher" or "scatours-service". For > example, > to run the "jumpstart" scenario, you would set your current > directory to the > binary distribution "launchers" directory and run the command > ant run-jumpstart > This runs the travel sample jar file scatours-launcher-jumpstart.jar > using a > classpath with the required runtime dependencies from the Tuscany > SCA binary > distribution. The location of the Tuscany SCA binary distribution > is specified > by the TUSCANY_HOME environment variable). > >> Looking at the sample descriptions I'd like to add a little more >> meat. >> For example. currently the description of the interaction sample is >> as >> follows: >> 4) Interaction - Different SCA interaction styles >> Command: ant run >> Directory: launchers/interaction >> Contributions: calendar, common, currency, flight, hotel, >> interaction-client, >> interaction-service-remote, shoppingcart >> I'd like to flip the Directory and Command lines and then add a >> description section as follows. > > > The Directory and Command lines were originally in the other other, > with Directory first. I changed the order of these when I added > descriptions of the .war samples because these start with a Webapp > line which I thought was more analogous to Command than to Directory. > However, on further reflection it seems that Webapp could equally well > be considered to be analogous to Directory, so I would be fine with > reverting to the previous order and putting Directory first. > >> I also added the directory/run >> command to for the binary distro but open to suggest about whether/ >> how >> to do this. >> 4) Interaction - Shows different SCA interaction styles >> Directory src(bin): launchers/interaction (launchers) >> Command src(bin): ant run (ant run-interaction) > > > This would need a reorganisation of the structure of the README so > that > the sections titled "Running the travel sample from the build > directories" > and "Running the travel sample from the distribution directories" are > merged together into a single section. I'm concerned that doing this > would be more confusing because of the mix of information appearing > together, where some of it only applies to one case or the other. > > An alternative would be to keep the present structure of sections > but add cross-references between them and perhaps also flesh out the > section "Running the travel sample from the distribution directories" > to be more explicit about all the commands that are needed. > > Another alternative would be to have a new section called something > like > "The travel sample scenarios" which describes the scenarios and > lists the > contributions/launchers/services/clients/webapps/URLs that they use, > but > doesn't go into full details of how to run them. These details > would be > provided in separate later sections, one for running from the build > directories and one for running from the binary distribution. This is > probably the best and clearest approach, and I'm happy to make the > edits > for this if others agree with this structure. > >> Contributions: calendar, common, currency, flight, hotel, >> interaction-client, >> interaction-service-remote, shoppingcart >> Description: Each SCA interaction pattern is >> demonstrated >> using a component from the travel booking application. >> We’re going to see the Hotel, Calendar, CurrencyConverter and >> ShoppingCart components used here. These components >> don't work in isolation so for each interaction pattern we've >> written a simple client component. For example, the >> InteractionLocalClient component demonstrates local interactions >> by sending a local message to the Calendar >> component. The sample launcher will run samples for all of the >> interaction patterns automatically.The launcher starts two >> nodes. Node1 loads the contributions common, currency, calendar, >> shoppingcart and interaction-client and runs the >> client.composite from the interaction-client contribution. All >> local interaction patterns are demonstrate by clients calling >> currency, calendar, and shoppingcart components locally, within >> node1. Node2 loads the contributions common, hotel, >> and interaction-service-remote, and runs the service.composite >> from the interaction-service-remote contribution. This node >> provides the hotel component that client components in node1 can >> send messages to remotely to demonstrate the >> remote interaction pattern. > +1 for adding more detailed descriptions of all the scenarios. > > Simon > >> Thoughts? >> Simon > > Received: from cas-hts01-sc.corp.shutterfly.com (172.16.200.215) by > CAS-HTS03-SC.corp.shutterfly.com (172.16.200.113) with Microsoft > SMTP Server > (TLS) id 14.0.682.1; Sun, 14 Mar 2010 16:32:31 -0700 > Received: from sms-sc03-sc.shutterfly.com (172.16.200.225) by > cas-hts01-sc.corp.shutterfly.com (172.16.200.215) with Microsoft > SMTP Server > id 8.2.213.0; Sun, 14 Mar 2010 16:32:30 -0700 > X-AuditID: ac10c8e0-b7c54ae00000414b-90-4b9d71b8dfd6 > Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) > by > sms-sc03-sc.shutterfly.com (Symantec Mail Security) with SMTP id > 1A.C8.16715.8B17D9B4; Sun, 14 Mar 2010 16:31:04 -0700 (PDT) > Received: (qmail 17522 invoked by uid 500); 14 Mar 2010 23:32:29 -0000 > Mailing-List: contact [email protected]; run by ezmlm > Precedence: bulk > List-Help: <mailto:[email protected]> > List-Unsubscribe: <mailto:[email protected]> > List-Post: <mailto:[email protected]> > List-Id: <dev.tuscany.apache.org> > Reply-To: <[email protected]> > Delivered-To: mailing list [email protected] > Received: (qmail 17515 invoked by uid 99); 14 Mar 2010 23:32:29 -0000 > Received: from nike.apache.org (HELO nike.apache.org) > (192.87.106.230) by > apache.org (qpsmtpd/0.29) with ESMTP; Sun, 14 Mar 2010 23:32:29 +0000 > X-ASF-Spam-Status: No, hits=0.7 required=10.0 > tests=RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_NEUTRAL > X-Spam-Check-By: apache.org > Received-SPF: neutral (nike.apache.org: local policy) > Received: from [212.227.126.186] (HELO moutng.kundenserver.de) > (212.227.126.186) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, > 14 Mar > 2010 23:32:19 +0000 > Received: from [115.189.182.54] (115-189-182-54.mobile.telecom.co.nz > [115.189.182.54]) by mrelayeu.kundenserver.de (node=mrbap0) with > ESMTP > (Nemesis) id 0M96Lt-1Nw9o12mlR-00D5xL; Mon, 15 Mar 2010 00:31:59 > +0100 > Message-ID: <[email protected]> > Date: Sun, 14 Mar 2010 23:31:58 +0000 > From: Simon Nash <[email protected]> > User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) > To: <[email protected]> > Subject: Re: Travel sample README questions/suggestions > References: <[email protected] > > > In-Reply-To: <[email protected] > > > Content-Type: text/plain; charset="windows-1252"; format=flowed > Content-Transfer-Encoding: 8bit > X-Provags-ID: V01U2FsdGVkX1+OwXLVH8WLcyecjVjFMhoo8rRm2RDW73Z6Uat > xLJAkzJPFC0pmpa9vvCPJZNRFRW5GR9ETt+r8XjIyBeclBN879 > 85Cqcx4xZeY2cSZL0IlPQ== > X-Virus-Checked: Checked by ClamAV on apache.org > X-Brightmail-Tracker: AAAAARM9rGc= > Return-Path: [email protected] > X-MS-Exchange-Organization-AVStamp-Mailbox: SMEX_Ka=;691700;0;This > mail has > been scanned by Trend Micro ScanMail for Microsoft Exchange; > X-MS-Exchange-Organization-SCL: 0 > X-MS-Exchange-Organization-AuthSource: cas-hts01- > sc.corp.shutterfly.com > X-MS-Exchange-Organization-AuthAs: Anonymous > MIME-Version: 1.0 > > Simon Laws wrote: >> Haven't looked at the travel sample README for a little while. Anyone >> know how up to date it is? > It should be fully up to date and in sync with the current svn code. > >> For example, the run commands are mostly given as "ant run" but this >> doesn't seem to be the case in the binary distribution. For example, >> from the binary distribution the interaction samples are run using >> "ant run-interaction". So maybe it's just that we need to spell out >> the different types of releases we will have and how to use them. In >> the src distro launchers and contributions will be directories while >> in the bin distro they will be jars. > The "ant run" commands are listed in the section titled "Running the > travel > sample from the build directories" and are correct when running from > the > build directories. For running from the binary distribution, there > is a > later section titled "Running the travel sample from the distribution > directories" which explains the commands needed in this case. Here > is the > paragraph from this section that describes this: > > To run a jar, you need to used the command "ant run-jarsuffix" where > "jarsuffix" is the last part of the jar file name omitting the > standard prefix > "scatours-client", "scatours-launcher" or "scatours-service". For > example, > to run the "jumpstart" scenario, you would set your current > directory to the > binary distribution "launchers" directory and run the command > ant run-jumpstart > This runs the travel sample jar file scatours-launcher-jumpstart.jar > using a > classpath with the required runtime dependencies from the Tuscany > SCA binary > distribution. The location of the Tuscany SCA binary distribution > is specified > by the TUSCANY_HOME environment variable). > >> Looking at the sample descriptions I'd like to add a little more >> meat. >> For example. currently the description of the interaction sample is >> as >> follows: >> 4) Interaction - Different SCA interaction styles >> Command: ant run >> Directory: launchers/interaction >> Contributions: calendar, common, currency, flight, hotel, >> interaction-client, >> interaction-service-remote, shoppingcart >> I'd like to flip the Directory and Command lines and then add a >> description section as follows. > > > The Directory and Command lines were originally in the other other, > with Directory first. I changed the order of these when I added > descriptions of the .war samples because these start with a Webapp > line which I thought was more analogous to Command than to Directory. > However, on further reflection it seems that Webapp could equally well > be considered to be analogous to Directory, so I would be fine with > reverting to the previous order and putting Directory first. > >> I also added the directory/run >> command to for the binary distro but open to suggest about whether/ >> how >> to do this. >> 4) Interaction - Shows different SCA interaction styles >> Directory src(bin): launchers/interaction (launchers) >> Command src(bin): ant run (ant run-interaction) > > > This would need a reorganisation of the structure of the README so > that > the sections titled "Running the travel sample from the build > directories" > and "Running the travel sample from the distribution directories" are > merged together into a single section. I'm concerned that doing this > would be more confusing because of the mix of information appearing > together, where some of it only applies to one case or the other. > > An alternative would be to keep the present structure of sections > but add cross-references between them and perhaps also flesh out the > section "Running the travel sample from the distribution directories" > to be more explicit about all the commands that are needed. > > Another alternative would be to have a new section called something > like > "The travel sample scenarios" which describes the scenarios and > lists the > contributions/launchers/services/clients/webapps/URLs that they use, > but > doesn't go into full details of how to run them. These details > would be > provided in separate later sections, one for running from the build > directories and one for running from the binary distribution. This is > probably the best and clearest approach, and I'm happy to make the > edits > for this if others agree with this structure. > >> Contributions: calendar, common, currency, flight, hotel, >> interaction-client, >> interaction-service-remote, shoppingcart >> Description: Each SCA interaction pattern is >> demonstrated >> using a component from the travel booking application. >> We’re going to see the Hotel, Calendar, CurrencyConverter and >> ShoppingCart components used here. These components >> don't work in isolation so for each interaction pattern we've >> written a simple client component. For example, the >> InteractionLocalClient component demonstrates local interactions >> by sending a local message to the Calendar >> component. The sample launcher will run samples for all of the >> interaction patterns automatically.The launcher starts two >> nodes. Node1 loads the contributions common, currency, calendar, >> shoppingcart and interaction-client and runs the >> client.composite from the interaction-client contribution. All >> local interaction patterns are demonstrate by clients calling >> currency, calendar, and shoppingcart components locally, within >> node1. Node2 loads the contributions common, hotel, >> and interaction-service-remote, and runs the service.composite >> from the interaction-service-remote contribution. This node >> provides the hotel component that client components in node1 can >> send messages to remotely to demonstrate the >> remote interaction pattern. > +1 for adding more detailed descriptions of all the scenarios. > > Simon > >> Thoughts? >> Simon >
