Meetup bangalore 9_novupdated

9th November 2019
Bangalore MeetUp Community

Networking time
Introduce yourself to your Neighbours!

All contents © MuleSoft Inc.
Agenda
3
10:30AM - 10:45 AM : Short Introductions
11:15AM - 11:45 PM : Developing An OData Enabled API In Mule
11:45AM - 12:15 PM : Thread Management & Auto-Tuning in Mule 4
12:15 PM - 12:45PM : Open forum discussion and Q&A
12:45PM - 1:00PM : Wrap up
1:00 PM : Snack Time

CHEERS..!!
4
We have prizes to give away!
As a Token for your Positive Participation and Enthusiasm
A SHOW OF HANDS:
New Members With Us.!!

Developing An OData Enabled API In Mule

Agenda
6
 What is OData ?
 Why the organizations adopting OData ?
 Prerequisites
 Anotomy Of URL
 Demo
 Q&A

What is OData ?
• It is an open data protocol , or OData built upon REST principles to
allow the creation and consumption of querable RESTful API’s.
•It is built upon EDM(Entity Data Model) data model and any client can
access metadata over the URL .

Why Organizations are adopting OData
8
 Operations are built upon REST principles.
 Easy access of metadata .
 OData is easy to learn , if we know SQL.
 It is open source , flexible and light-weight .

Prerequisites
9
The following software is required for creating and using an OData-enabled API
with APIkit:
 OData Plugin
 Mule EE 4.1.1 and later
 Anypoint Studio 7.1.4 and later
 Maven
Installing the APIKit OData Extension
https://docs.mulesoft.com/apikit/4.x/creating-an-odata-api-with-apikit

Anatomy of URL
10
http://localhost:8081/api/odata.svc/customers(1)/products?$select=CompanyName&&$filter=CompanyName eq 'Bottom-Dollar'
Source Root URI : http://localhost:8081/api/odata.svc/
Resource path : customers(1)/products
Query options : $select=CompanyName&&$filter=CompanyName eq 'Bottom-Dollar'

Demo
 Synchronizing Data between Mysql and Salesforce
Using OData API
 Generating BI report in Tableau using OData API

All contents © MuleSoft Inc. 12

Thread Management &
Auto-Tuning
in
Mule 4
Gaurav & Swapnil

Agenda
16
 Thread Management and How it is done in Mule 4?
 Different Thread Pools in Mule 4
 Live Interactive Example Plus Demo
 Q&A

Centralized Thread Pools
• Mule 4 eradicates the need for manual thread pool configuration as
this is done automatically by the Mule runtime.
• Thread pools are no longer configurable at the level of a Mule
application. We now have three centralized pools:
 CPU_INTENSIVE
 CPU_LITE
 BLOCKING_IO
• Mule 4 optimizes the execution of a flow to avoid unnecessary
thread switches.

HTTP Thread Pools
• The Mule 4 HTTP module uses Grizzly under the covers, which needs
selector thread pools configured.
• The concept of selector threads was introduced with J2SE 1.4 release, that
introduced JAVA NIO (Non Blocking I/O), which checks the state of NIO
channels and create and dispatch events when they arrive
• HTTP Listener selectors poll for request events only.
HTTP Requester selectors poll for response events only.

HTTP Thread Pools (contd..)
• There is a Special Thread Pool for the HTTP Listener as well as HTTP
Requester.!!
• Configured at the Mule runtime level and shared by all applications
deployed to that runtime.
• 2 applications on one runtime both using an HTTP Requester will have
one selector pool each for that HTTP Requester. Same goes for HTTP
Listener.

Thread pool responsibilities
• The source of the flow and each event processor must execute in a
thread that is taken from 1 of the 3 centralized thread pools (plus
selector threads needed by HTTP Listener and Requester)
• The task accomplished by an event processor is either 100%
nonblocking, partially blocking, or mostly blocking.

Thread pool responsibilities (contd..)
• The CPU_LITE pool is for tasks that are 100% non-blocking and take <
10ms to complete.
• The CPU_INTENSIVE pool is for tasks that take > 10ms and are
potentially blocking less than 20% of the clock time.
• The BLOCKING_IO pool is for tasks that are blocked most of the time.

Thread pool sizing
• The minimum size of the three thread pools is determined when the
Mule runtime starts up.
• The minimum size of the shared Grizzly pool for the HTTP Listener is
determined upon the deployment of the first app to the Mule runtime
that uses an HTTP Listener.
• The size of the dedicated Grizzly for the HTTP Requester pool is
determined upon deployment of each app that uses an HTTP Requester.

Thread pool sizing (contd..)
• The minimum size of the three thread pools is determined when the
Mule runtime starts up.
• In all cases, the min no.
of threads equal the no. of
CPU cores available to the
Mule runtime.
• The size of the dedicated
Grizzly for HTTP Requester
pool is determined upon
deployment of each app that uses an HTTP Requester.

Thread pool sizing (contd..)
• For a Mule runtime sitting on a 2 core / 1 Gig machine or container,
the following table shows what the minimum and maximum values
are for each thread pool –

Thread Pool Scheduler Assignment Criteria
• Each of the five pools discussed previously has its own Scheduler.
When a Mule 4 app is deployed each of its event processors is
assigned a Scheduler following the criteria as –

Mule Runtime Example for Consumption Of Thread Pools

What’s next
29
• Share:
– Tweet your pictures with the hashtag #BangaloreMuleMeetup
– Share the pics in WhatsApp group
• Let the community know you.. 
– Invite your network to join: https://meetups.mulesoft.com/bangalore/
• Feedback:
– Contact either Rajesh, Gaurav, Pruthvi or, Swapnil to suggest topics for
next meetup
– Contact MuleSoft at meetup@mulesoft.com for ways to improve the
program

Meetup bangalore 9_novupdated

More Related Content

Meetup bangalore 9_novupdated