> AS2 Communication for exchanging data between Sender and Receiver. > One Way SSL and Two Way SSL with MuleSoft > Evolution of Thread Management in MuleSoft

1. [13th June 2020]: [AS2 Communication, One Way SSL and
Two Way SSL with MuleSoft and Evolution of Thread
Management in MuleSoft]
[Mumbai - India]

2. All contents © MuleSoft Inc. 2
• 1.Please keep yourself muted unless you have any question.
• 2.We encourage keeping your video for making our meetup
interactive.
• 3.You'll can also write down your questions in chat section.
• 4.Once you join write down your registered name in chat section so
we will have an attendance.
• 5.As this is our first online Meetup we appreciate your valuable
feedback. Thanks.
Guidelines for Mumbai MuleSoft Meetup #11 [Online]

3. All contents © MuleSoft Inc. 3
• Training and certification update:
• Any certification set to expire on or after Feb 1, 2020 is now
valid through July 31, 2020.
• MuleSoft Global Connect is Virtual! Register for free to be a part.
https://connect.mulesoft.com/
• APAC ETA – 25th June 2020
Important Announcements

4. All contents © MuleSoft Inc.
Agenda
4
 Introductions
 Thread Management- Terminologies
 Thread Management in Mule 3
 Thread Management in Mule 4.1.x/4.2.x
Thread Management in Mule 4.3.x
 Implementation and Demonstration of One Way SSL Using MuleSoft
 Implementation and Demonstration of Two Way SSL Using MuleSoft (Mutual
Authentication)
 Implementation and Demonstration of AS2 Communication Using MuleSoft
 Networking time

5. All contents © MuleSoft Inc.
Introductions
5
• About the organizers:
– Sudeshna Mitra
– Manish Yadav
– Akshata Sawant
• About the sponsors: MuleSoft
A SHOW OF HANDS:
Who is new to this MeetUp?

6. All contents © MuleSoft Inc.
Speaker
6

7. Thread Management -
Terminologies

8. All contents © MuleSoft Inc.
Thread Management - Terminologies
8
• Thread
– A thread is the smallest entity during execution of process
– Each thread has its own program counter, stack and local variables
• Multithreading - Executing multiple threads simultaneously
• Thread pool - A thread pool is a group of pre-instantiated, idle
threads which are available to pick new task.

9. All contents © MuleSoft Inc.
Thread Management
9
• Task Execution : When a new task comes up, a thread is taken from
thread pool and once the task if completed it returns to normal state,
when multiple tasks come up the threads are taken from the pool and
are executed parallelly.
• Thread scheduler in java is the part of the JVM that decides which
thread should run.
• Primary purpose of multithreading is to provide simultaneous
execution of two or more parts of a program to maximum utilize the
CPU time.

10. Thread Management in Mule

11. All contents © MuleSoft Inc.
Thread Management in Mule 3
11
• Each request that comes into Mule is processed on its own thread.
• A connector’s receiver has a thread pool with a certain number of
threads available to process requests on the inbound endpoints that
use that connector.
• Mule can send messages asynchronously or synchronously depending
upon.
– Processing Strategy
– Transactions
– Message exchange pattern
– Outbound endpoint (One-way, Request-response)

12. All contents © MuleSoft Inc.
Synchronous vs Asynchronous Processing
12

13. All contents © MuleSoft Inc.
Threads and processing strategies
13
• Types of Threads
– The Receiver thread, which originally receives the message, either:
• Processes the entire flow (synchronous), or
• Ends by writing the message to a SEDA queue (asynchronous)
– The Flow thread, which processes the bulk of the flow (asynchronous)
– Dispatcher threads, which send messages to one-way endpoints
(asynchronous)
• Processing Strategies
– Default (Synchronous / Queued Asynchronous)
– Non-blocking (3.7 and later)
– Thread per processor
– Queued thread per processor
– Asynchronous

14. All contents © MuleSoft Inc.
Can I fine tune the threading profile ?
14
• Yes,at three levels
– Configuration level
– Connector level
– Flow level
• Important Attributes at connector/configuration level
– maxThreadsActive (Default: 16)
– maxThreadsIdle (Default: 1)
– poolExhaustedAction (Default: RUN)
• Important Attributes at Flow level
– maxThreads
– minThreads
– poolExhaustedAction(Default: RUN)

15. All contents © MuleSoft Inc.
Thread Management in Mule 4.1.x and 4.2.x
15
• Mule 4 has an improved execution engine that simplifies the
development and scaling of Mule apps. How ?
– No need of manual thread pool configuration as this is done automatically by
the Mule runtime.
– No need to select flow processing strategies.
– We now have three centralized pools:
• CPU_INTENSIVE
• CPU_LITE
• BLOCKING_IO
– Special HTTP Thread pools:
• GRIZZLY (Shared)
• GRIZZLY (Dedicated)

16. All contents © MuleSoft Inc.
Thread Pool Sizing
16

17. All contents © MuleSoft Inc.
Scheduler Assignments
17
• When a Mule 4 app is deployed each of its event processors is
assigned a Scheduler.
– CPU_INTENSIVE : Dataweave or Scripting Module
– BLOCKING_IO : All blocking operations, Database Calls, SFTP Reads ,
Transactional Scopes etc
– CPU_LITE: All other event processors, scopes and routers.
– GRIZZLY (Shared) : HTTP Listener
– GRIZZLY (Dedicated): HTTP Requestors

18. All contents © MuleSoft Inc.
Thread switching scenario
18

19. All contents © MuleSoft Inc.
Mule 4: Automatic Back Pressure
19
• Mule 4 provides an automatic configuration that provides a back pressure
signal when all threads are currently executing and no free threads
remain in the required thread pool.
• This at times will trigger HTTP Listener to respond with “503-Service
Unavailable”
• This configuration avoids Out of Memory Errors. One of the main
advantages of using Mule 4

20. All contents © MuleSoft Inc.
Mule 4: Manual Back Pressure
20
• One can attain manual back pressure by using a property
“maxConcurrency” to handle large influx of messages.
• This configuration might affect the throughput, but will ensure reliability
of messages and avoid messages being lost.
• One can use it to stop getting new requests once the current one have
been processed successfully.

21. All contents © MuleSoft Inc.
Thread Management in Mule 4.3.x
21
• Mule is getting smarter ! How ?
– Mule 4.3 introduced one unique thread pool - The UBER pool.
– At startup, Mule introspects the available resources (such as memory and CPU
cores) in the system and tunes automatically for the environment where Mule
is running.
– It follows Proactor design pattern for asynchronous execution.
– Proactor pattern allows threads to return to the main loop more quickly,
allowing the system to continue to accept new work while the I/O tasks are
blocked and waiting.
– Whenever there was a thread switch before, there’s still a thread switch in
Mule 4.3, the only thing that changes is the target pool.

22. All contents © MuleSoft Inc.
Custom Thread Pools
22
• Besides the unique UBER thread pool, some components might
create additional pools for specific purposes:
– NIO Selectors
• Enables Non blocking IO
– Recurring tasks pools
• Some connectors or components (expiration monitors, queue consumers, and so
on) might create specific pools to perform recurring tasks.

23. All contents © MuleSoft Inc.
Can I go back to Dedicated thread pools ?
23
• Of-course, Yes !
– You can modify these global formulas by editing the
MULE_HOME/conf/schedulers-pools.conf file in your local Mule instance.

24. All contents © MuleSoft Inc.
Scheduler Configurations
24
• UBER
– org.mule.runtime.scheduler.uber.threadPool.coreSize=cores
– org.mule.runtime.scheduler.uber.threadPool.maxSize=max(2, cores + ((mem -
245760) / 5120))
– org.mule.runtime.scheduler.uber.workQueue.size=0
– org.mule.runtime.scheduler.uber.threadPool.threadKeepAlive=30000
• DEDICATED
– org.mule.runtime.scheduler.cpuLight.threadPool.size=2*cores
– org.mule.runtime.scheduler.cpuLight.workQueue.size=0
– org.mule.runtime.scheduler.io.threadPool.coreSize=cores
– org.mule.runtime.scheduler.io.threadPool.maxSize=max(2, cores + ((mem -
245760) / 5120))
– org.mule.runtime.scheduler.io.workQueue.size=0
– org.mule.runtime.scheduler.io.threadPool.threadKeepAlive=30000
– org.mule.runtime.scheduler.cpuIntensive.threadPool.size=2*cores
– org.mule.runtime.scheduler.cpuIntensive.workQueue.size=2*cores

25. All contents © MuleSoft Inc.
Application level configuration
25
<ee:scheduler-pools poolStrategy="UBER" gracefulShutdownTimeout="15000">
<ee:uber
corePoolSize="1"
maxPoolSize="9"
queueSize="5"
keepAlive="5"/>
</ee:scheduler-pools>
<ee:scheduler-pools gracefulShutdownTimeout="15000">
<ee:cpu-light
poolSize="2"
queueSize="1024"/>
<ee:io
corePoolSize="1"
maxPoolSize="2"
queueSize="0"
keepAlive="30000"/>
<ee:cpu-intensive
poolSize="4"
queueSize="2048"/>
</ee:scheduler-pools>

26. Implementing One Way SSL Using
MuleSoft

27. All contents © MuleSoft Inc.
What is SSL?
27
SSL (Secure Socket Layer) is the standard technology used for enabling secure
communication between a client and server to ensure data security & integrity.
Various version of SSL has been released.
• SSL V2 in 1995
• SSL V3 in 1996.
• TLS V1.0 is 1999.
• TLS V1.1 in 2006.
• TLS V1.2 in 2008.

28. All contents © MuleSoft Inc.
How One Way SSL Works?
28
In one way SSL, only client validates the server to ensure that it receives data from the
intended server. For implementing one-way SSL, server shares its public certificate with the
clients.

29. All contents © MuleSoft Inc.
SSL Keystore Commands
29
Generate Server Keystore
keytool -genkey -alias mule-server -keyalg RSA -keystore server-keystore.jks
Extract Public Key from Server Keystore
keytool -export -alias mule-server -keystore server-keystore.jks -file erver_trust.crt
Generate Client Truststore
keytool -import -alias mule-server -keystore client-truststore.jks -file server_trust.crt

30. Demonstration on One Way SSL Using
MuleSoft

31. Implementing Two Way SSL Using
MuleSoft (Mutual Authentication)

32. All contents © MuleSoft Inc.
How Two Way SSL Works?
32
In case of two-way SSL, both client and server authenticate each other to ensure that both
parties involved in the communication are trusted. Both parties share their public certificates
to each other and then verification/validation is performed based on that.

33. All contents © MuleSoft Inc.
How Two Way SSL Works?
33
1. A client requests access to a protected resource.
2. The server presents its certificate to the client.
3. The client verifies the server’s certificate.
4. If successful, the client sends its certificate to the server.
5. The server verifies the client’s credentials.
6. If successful, the server grants access to the protected resource requested by the client.

34. All contents © MuleSoft Inc.
SSL Keystore Commands
34
Generate Server Keystore
keytool -genkey -alias mule-server -keyalg RSA -keystore server-keystore.jks
Extract Public Key from Server Keystore
keytool -export -alias mule-server -keystore server-keystore.jks -file server_trust.crt
Generate Client Truststore
keytool -import -alias mule-server -keystore client-truststore.jks -file server_trust.crt
Generate Client Keystore
keytool -genkey -alias mule-client -keyalg RSA -keystore client-keystore.jks
Extract Public Key from Client Keystore
keytool -export -alias mule-client -keystore E:SSLDemoclient-keystore.jks -file client_trust.crt
Generate Server Truststore
keytool -import -alias mule-client -keystore server-truststore.jks -file client_trust.crt

35. Demonstration on Two Way SSL Using
MuleSoft

36. Implementing AS2 Communication With
MuleSoft

37. All contents © MuleSoft Inc.
What IS AS2
37
AS2 protocol combines the use of several secure and widely used technologies including
HTTPS, SSL Certificates, S/MIME, and file hashing. By utilizing the strengths of each of them,
AS2 has become the preferred protocol in many organizations for exchanging sensitive EDI
files.
AS2 messages can be compressed, signed, encrypted and sent over an SSL tunnel making the
file transfers very secure. And receipts can be sent back to the sender ensuring the messages
were delivered successfully. The receipts can be digitally signed and will contain a checksum
value that the sender will use to verify the message received is identical to what was sent.

38. All contents © MuleSoft Inc.
AS2 Features
38
● Message Encryption - By using the recipient's public certificate, the AS2 message contents can be
encrypted to keep the data secure. Only the recipient will be able to decrypt the contents using their
private certificate.
● Digital Signatures - The message can be signed using the sender's private certificate which allows
the recipient to verify the authenticity of the sender. The receipt that is sent back to the sender can
also be signed to ensure the identity of the recipient's system. These digital signatures are used for
message integrity and non-repudiation of origin. They are typically used in addition to authentication
using a username, password, and/or certificate.
● Compression - In order to improve transmission time, compression can be added to decrease the
size of the message.
● Receipt - The Message Disposition Notification (MDN, which is commonly referred to as a receipt)
plays an important role in AS2 protocol as it acknowledges that the recipient received the message. It
can also be used to verify the identity of the recipient when the receipt is signed. Receipts that are
sent back immediately over the same connection are referred to as a synchronous MDN. Receipts can
also be sent back at a later time in asynchronous mode. This allows the recipient to process and
verify the data before sending back a status to indicate if the transaction was successful.

39. All contents © MuleSoft Inc.
AS2 Connector & Operations
39
Mule supports the AS2 protocol through the AS2 Connector. The AS2 connector enables
trading partners to transmit and receive AS2 messages with EDI-X12, EDIFACT, XML or binary
payloads.
This connector leverages the AS2 protocol, allowing Mule applications to:
• Send messages, signed or unsigned, over HTTP or HTTPS, following the AS2 protocol.
• Receive messages, also over HTTP or HTTPS, following the protocol.
Operations
• Send: Sends a message through HTTP or HTTPS using the AS2 protocol.
• Receive: Source that receives messages via HTTP or HTTPS using the AS2 protocol.

40. All contents © MuleSoft Inc.
AS2 Communication Between Two Parties
40

41. Demonstration on AS2 Communication
Using MuleSoft

42. All contents © MuleSoft Inc.
References / Resources
42
 https://blogs.mulesoft.com/biz/mule/thread-management-auto-tuning-mule-4/
 https://docs.mulesoft.com/mule-runtime/4.2/intro-engine
 https://blogs.mulesoft.com/dev/anypoint-platform-dev/threading-model-in-mule-
4-3/
 https://docs.mulesoft.com/mule-runtime/4.3/intro-engine
 https://docs.mulesoft.com/mule-runtime/3.9/tuning-performance
 Implementing One Way SSL for MuleSoft Application
https://youtu.be/twQgRW1Er7s
 Implementing 2-Way SSL (Mutual Authentication) For MuleSoft
Application https://youtu.be/R5QCAtYuy7A
 Establishing AS2 Communication between Sender and Receiver using
MuleSoft AS2 Connector https://youtu.be/4uePAI8FG_w

43. All contents © MuleSoft Inc.
Take a stand !
43
• Nominate yourself for
the next meetup speaker
and suggest a topic as
well.

44. All contents © MuleSoft Inc.
What’s next
44
• Share:
– Tweet your pictures with the hashtag #MuleMeetup #MuleSoftMeetup
– Invite your network to join: https://meetups.mulesoft.com/mumbai/
• Feedback:
– Contact your organizers Manish Yadav, Sudeshna Mitra and Akshata Sawant to suggest topics
– Tweet your organizers at @SudeshnaMitra14, @Manish_Kyadav, @sawantakshata02
– Contact MuleSoft at meetup@mulesoft.com for ways to improve the program
– Follow us on Instagram (mumbai_mulesoftofficialpage)
– Your Feedback is Food for us
• Our next meetup:
– Date: TBD
– Location: Mumbai
– Topic: TBD

45. Networking time
Introduce yourself to your neighbors!

46. See you next time
Please send topic suggestions to the organizer

47. THANK YOU