Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

iiwas 2010

422 views

Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

iiwas 2010

  1. 1. Thread Management in Mashup Execution Platforms Michele Stecca and Massimo Maresca Computer Platform Research Center (CIPI) University of Padova & Genova (Italy) Paris – Gennevilliers November 10, 2010
  2. 2. Agenda <ul><li>Introduction </li></ul><ul><li>Overview of the Platform </li></ul><ul><li>Classification of Service Components </li></ul><ul><li>Case Study: Polling Services </li></ul><ul><li>Conclusions and Future Work </li></ul>
  3. 3. 1. Introduction (1/4) <ul><li>Scenario </li></ul><ul><li>Availability of contents and services through Web 2.0 technologies such as RSS Feed, Atom, REST-WS, SOAP-WS, etc. </li></ul><ul><li>Availability of tools for the rapid development of convergent Composite Services (a.k.a. Mashups) that combine different resources/contents such as Yahoo Pipes!, JackBe Presto, etc. </li></ul>
  4. 4. 1. Introduction (2/4) <ul><li>Mashup classification based on execution platform location </li></ul><ul><li>The analysis is about Server Side Mashup Execution Platforms </li></ul><ul><ul><li>Long Running Executions (i.e., user can be also “offline”) </li></ul></ul><ul><ul><li>User Terminal power consumption and availability (e.g., it may be disconnected) </li></ul></ul><ul><ul><li>Security (e.g., private data, malicious components, etc.) </li></ul></ul>Server side Client side SC1 SC2 SCN User Node (Browser) SC1 SC2 SCN Browser (User) Mashup Engine (Server) Request Results
  5. 5. 1. Introduction (3/4) <ul><li>We refer to Event Driven Mashups (i.e., Composite Services in which Service Components generate events during the execution) </li></ul><ul><li>Remarks </li></ul><ul><ul><li>Server Side execution model (long running Mashups) </li></ul></ul><ul><ul><li>Event driven model to cope with Telecom Operator services (calls, SMS, etc.) </li></ul></ul>
  6. 6. 1. Introduction (4/4) <ul><li>Thread Management </li></ul><ul><li>The Mashup Execution Engine must manage a huge number of concurrent Mashup executions called Sessions </li></ul><ul><li>Throughput, Latency and Scalability are the key issues to support the efficient execution of Mashup Sessions </li></ul><ul><li>The number of concurrent Threads highly influences the Mashup Execution Engine performance </li></ul><ul><li>We have explored the following two design choices: </li></ul><ul><ul><li>Using an already existing standard platform (e.g., JEE compliant platforms like red Hat JBoss, Sun Glassfish, etc.) </li></ul></ul><ul><ul><ul><li> General purpose Thread Model </li></ul></ul></ul><ul><ul><li>Implementing the execution platform from scratch </li></ul></ul><ul><ul><ul><li> Mashup specific Thread Model (i.e., complete control on resources consumption) </li></ul></ul></ul>
  7. 7. 2. Overview of the platform (1/2) <ul><li>The Orchestrator executes the Logic of the Composite Service </li></ul><ul><li>Each Service Proxy </li></ul><ul><ul><li>Wraps one external functionality </li></ul></ul><ul><ul><li>Interacts with the Orchestrator through a standard interface </li></ul></ul><ul><ul><li>Interacts with the external resource through a specific protocol </li></ul></ul><ul><li>External resources are made available by 3rd Parties </li></ul>
  8. 8. 2. Overview of the platform (2/2) <ul><li>From a Platform (Container)-based solution to the Monolithic approach </li></ul>
  9. 9. 3. Service Component Classification <ul><li>Call-Response: the service is exposed by the service provider to consumers through a synchronous invocation (e.g., a Web Service). The consumer invokes the service and blocks until the service provider returns the result </li></ul><ul><li>Polling: the service is exposed by the service provider to consumers through a synchronous invocation (e.g., a Web Service) or through a syndication technology (e.g., an RSS Feed). The consumer keeps on polling the service and retrieves the desired content when available </li></ul><ul><li>Callback: the service is exposed through a synchronous invocation (e.g., a Web Service). The consumer issues such an invocation to activate the external service and to configure a “callback URL”, to be used by the external service to notify events that are of interest for the consumer. </li></ul>
  10. 10. 4. Case study: Polling Services (1/2) <ul><li>Trivial Solution: One Thread for each active Polling Service invocation </li></ul><ul><li>Proposed Solution: One Thread (see code below) + Fixed Thread Pool for each Polling Service </li></ul>1. While (true) { 2. Sleep (Period) 3. For each entry in <Set of Active Invocations> { 4. Extract the input props 5. Use input props to access the external resource 6. if (the desired state change occurred) { 7. Create a new Task T 8. Submit T to the Thread Pool for execution 9 }//end if 10. }//end For each 11.}//end while
  11. 11. 4. Case study: Polling Services (2/2) <ul><li>Comparison of the two solutions: </li></ul><ul><li>Memory Consumption (due to the allocation of Thread Stack + Objects in the JVM Heap): </li></ul><ul><ul><li>Uncontrolled in the trivial case (it depends on the number of Service Invocations) </li></ul></ul><ul><ul><li>Bounded in the proposed solution (proportional to 1 + Thread Pool size ) </li></ul></ul><ul><li>Response time (influenced by the heavy Thread creation procedure): </li></ul><ul><ul><li>250000 requests satisfied in 41,3 secs in the trivial case </li></ul></ul><ul><ul><li>250000 requests satisfied in 20,6 secs in the proposed solution </li></ul></ul><ul><ul><li>The difference is due to the Thread creation time: </li></ul></ul><ul><ul><li>0,08 ms * 250000 = 20 secs </li></ul></ul><ul><li>Note: 0.08 secs = creation time of a single Thread in the testing machine </li></ul>
  12. 12. 5. Conclusions and Future Work <ul><li>We propose a classification of the Component Service activation paradigms: </li></ul><ul><ul><li>Call-Response </li></ul></ul><ul><ul><li>Polling </li></ul></ul><ul><ul><li>Callback </li></ul></ul><ul><li>We propose an ad-hoc Thread Management model based on such a classification to overcome the limitations of general purpose platforms </li></ul><ul><li>We have presented some preliminary performance test results </li></ul><ul><li>Future Work: </li></ul><ul><ul><li>Analysis of the interaction between the JVM MM / Operating System MM </li></ul></ul><ul><ul><li>Effects of the Garbage Collections on the system performance </li></ul></ul>
  13. 13. Thank you for your attention

×