This document discusses how to make Java EE applications more reactive. It describes traditional synchronous approaches that can cause threads to wait idly. Various asynchronous techniques are presented, including spawning new threads, finishing requests in callbacks, and using CompletableFuture. The document also outlines reactive features in Java EE like the asynchronous API, and how Payara Micro enables simple messaging and caching across instances through automatic clustering. Overall it advocates a gradual approach to reactivity in Java EE to avoid over-engineering while leaving room for future improvements.
Owning Web Performance with PhantomJS 2 - Fluent 2016Wesley Hales
Running a synthetic testing server or script to measure web performance is a great entry point into the world of automated web-page testing. We have an abundance of standardized APIs to measure every part of how the page renders in the browser. PhantomJS 2, released in 2015, gives us the ability to measure navigation timing APIs in an automated fashion.
Wesley Hales introduces the basics of creating a simple PhantomJS script that only extracts the performance data we need (from the W3C Navigation Timing API) and explains how this script can be Dockerized and run across many different nodes and regions of the Web. You’ll walk away with a new view on automated web-performance testing and the tools required to setup a simulated RUM network.
Owning Web Performance with PhantomJS 2 - Fluent 2016Wesley Hales
Running a synthetic testing server or script to measure web performance is a great entry point into the world of automated web-page testing. We have an abundance of standardized APIs to measure every part of how the page renders in the browser. PhantomJS 2, released in 2015, gives us the ability to measure navigation timing APIs in an automated fashion.
Wesley Hales introduces the basics of creating a simple PhantomJS script that only extracts the performance data we need (from the W3C Navigation Timing API) and explains how this script can be Dockerized and run across many different nodes and regions of the Web. You’ll walk away with a new view on automated web-performance testing and the tools required to setup a simulated RUM network.
MEAN Stack is a full-stack JavaScript solution that helps you build fast, robust and maintainable production web applications using MongoDB, Express, AngularJS, and Node.js.
Slow Clients Are Problematic
Most benchmarks we've seen don't tell you this, and unicorn doesn't care about slow
clients... but you should.
-- The Philosophy Behind unicorn
No Container: a Modern Java Stack with BootiqueAndrus Adamchik
Java containers appeared back in the era of big expensive hardware and monolithic applications, and currently feel like an impediment to Java progress. More and more developers opt out of containers in favor of runnable jars, especially with the advance of microservices architectures. Andrus Adamchik will present a new open source tool called Bootique (https://bootique.io), a pluggable and extensible technology intended for various kinds of container-less Java apps – REST services, webapps, job runners, desktop apps and what not.
Lift web framework is one of the most popular parts of Scala ecosystem. Thanks to many innovative features and its use in projects such as foursquare or snapsort, this web framework popularity is skyrocketing. Moreover, for many developers, this web framework is the main reason to study Scala programming language.
Refactoring Into Microservices 2016-11-08Derek Ashmore
This presentation was given to the Illinois Java Users Group on November 8, 2016.
Microservices architecture has become a widely popular topic. Most of us are aware of what microservices are and the problems they are meant to solve. Most microservice implementations were originally monolithic applications that grew too large and complex to support. However, refactoring into microservices is much easier said than done.
This presentation will provide you guidance for refactoring a monolithic application into microservices. I'll provide an overview of the entire process along with best practices and common mistakes along the way. This presentation is meant to be platform-generic; you can use these concepts on applications written in any programming language. This presentation is targeted for senior developers and tech leads.
Đây là sự kiện mà ITEC hợp tác cùng cộng đồng AWS Việt Nam tổ chức:
Diễn giả: Bùi Kiên Cường và Quân Phương trình bày.
Thời gian: 22-09-2016, tại Hatch!Nest Hà Nội.
The goal of MicroProfile is to optimise Java EE for a micro-service architecture. It is based on some of the Java EE specifications and standardise a few technologies from the micro-services space.
However, some of the MicroProfile implementations are completely different 'servers', like the KumuluzEE server. So how can you migrate easily from your favorite Java EE server to a MicroProfile implementation?
This session shows you an overview of what MicroProfile.IO is and how it relates to Java EE. It then demonstrates with a few examples how you can adjust your Java EE application to incorporate some of the MicroProfile.IO specifications and how you can transform your Java EE application to a MicroProfile.IO one using Thorntail, Payara Micro, and KumuluzEE.
How to bake reactive behavior into your Java EE applicationsOndrej Mihályi
You will witness that Java EE is a modern and evolving framework and you’ll learn how it supports reactive concepts by many examples and live demonstration. The latest version of Java EE together with Java 8 add even more asynchronous API to write fully reactive applications. Several Java EE implementations, like Payara Micro, go even further and provide extensions to scale your applications in a natural way.
As presented at GeeCON Prague 2016. Almost the same slides used at JDD Krakow 2016 and CZJUG Hradec Kralove.
How to bake reactive behavior into your Java EE applicationsOndrej Mihályi
You will witness that Java EE is a modern and evolving framework and you’ll learn how it supports reactive concepts by many examples and live demonstration. The latest version of Java EE together with Java 8 add even more asynchronous API to write fully reactive applications. Several Java EE implementations, like Payara Micro, go even further and provide extensions to scale your applications in a natural way.
Presented at Java2Days 2016 in Sofia.
Sources on github: https://github.com/OndrejM-demonstrations/Reactive-CargoTracker
MEAN Stack is a full-stack JavaScript solution that helps you build fast, robust and maintainable production web applications using MongoDB, Express, AngularJS, and Node.js.
Slow Clients Are Problematic
Most benchmarks we've seen don't tell you this, and unicorn doesn't care about slow
clients... but you should.
-- The Philosophy Behind unicorn
No Container: a Modern Java Stack with BootiqueAndrus Adamchik
Java containers appeared back in the era of big expensive hardware and monolithic applications, and currently feel like an impediment to Java progress. More and more developers opt out of containers in favor of runnable jars, especially with the advance of microservices architectures. Andrus Adamchik will present a new open source tool called Bootique (https://bootique.io), a pluggable and extensible technology intended for various kinds of container-less Java apps – REST services, webapps, job runners, desktop apps and what not.
Lift web framework is one of the most popular parts of Scala ecosystem. Thanks to many innovative features and its use in projects such as foursquare or snapsort, this web framework popularity is skyrocketing. Moreover, for many developers, this web framework is the main reason to study Scala programming language.
Refactoring Into Microservices 2016-11-08Derek Ashmore
This presentation was given to the Illinois Java Users Group on November 8, 2016.
Microservices architecture has become a widely popular topic. Most of us are aware of what microservices are and the problems they are meant to solve. Most microservice implementations were originally monolithic applications that grew too large and complex to support. However, refactoring into microservices is much easier said than done.
This presentation will provide you guidance for refactoring a monolithic application into microservices. I'll provide an overview of the entire process along with best practices and common mistakes along the way. This presentation is meant to be platform-generic; you can use these concepts on applications written in any programming language. This presentation is targeted for senior developers and tech leads.
Đây là sự kiện mà ITEC hợp tác cùng cộng đồng AWS Việt Nam tổ chức:
Diễn giả: Bùi Kiên Cường và Quân Phương trình bày.
Thời gian: 22-09-2016, tại Hatch!Nest Hà Nội.
The goal of MicroProfile is to optimise Java EE for a micro-service architecture. It is based on some of the Java EE specifications and standardise a few technologies from the micro-services space.
However, some of the MicroProfile implementations are completely different 'servers', like the KumuluzEE server. So how can you migrate easily from your favorite Java EE server to a MicroProfile implementation?
This session shows you an overview of what MicroProfile.IO is and how it relates to Java EE. It then demonstrates with a few examples how you can adjust your Java EE application to incorporate some of the MicroProfile.IO specifications and how you can transform your Java EE application to a MicroProfile.IO one using Thorntail, Payara Micro, and KumuluzEE.
How to bake reactive behavior into your Java EE applicationsOndrej Mihályi
You will witness that Java EE is a modern and evolving framework and you’ll learn how it supports reactive concepts by many examples and live demonstration. The latest version of Java EE together with Java 8 add even more asynchronous API to write fully reactive applications. Several Java EE implementations, like Payara Micro, go even further and provide extensions to scale your applications in a natural way.
As presented at GeeCON Prague 2016. Almost the same slides used at JDD Krakow 2016 and CZJUG Hradec Kralove.
How to bake reactive behavior into your Java EE applicationsOndrej Mihályi
You will witness that Java EE is a modern and evolving framework and you’ll learn how it supports reactive concepts by many examples and live demonstration. The latest version of Java EE together with Java 8 add even more asynchronous API to write fully reactive applications. Several Java EE implementations, like Payara Micro, go even further and provide extensions to scale your applications in a natural way.
Presented at Java2Days 2016 in Sofia.
Sources on github: https://github.com/OndrejM-demonstrations/Reactive-CargoTracker
JDD 2016 - Andrej Mihály - How To Bake Reactive Behavior Into Your Java Ee Ap...PROIDEA
Reactive applications are flexible and robust. Reactive programming is already an established concept and there are many modern frameworks and tools which support it. You need to understand the concept in order to build truly reactive applications. But you do not need to switch from what you already know to build them. With standard Java EE you have wide range of options to add reactive behavior to new and even existing applications.
I will show that Java EE is a modern and evolving framework, which supports reactive concepts. The latest versions of JDK and Java EE add even more asynchronous API to write fully reactive applications. On top of asynchronous processing in servlets, REST services and EJBs, there is asynchronous IO, managed multithreading and CompletableFuture with its promise-like API to tackle callback hell. Several Java EE implementations, like Payara Micro, go even further and provide extensions to scale your applications in natural way.
JDD 2016 - Ondrej Mihalyi - How to bake reactive behavior into your Java EE ...PROIDEA
Reactive applications are flexible and robust. Reactive programming is already an established concept and there are many modern frameworks and tools which support it. You need to understand the concept in order to build truly reactive applications. But you do not need to switch from what you already know to build them. With standard Java EE you have wide range of options to add reactive behavior to new and even existing applications.
I will show that Java EE is a modern and evolving framework, which supports reactive concepts. The latest versions of JDK and Java EE add even more asynchronous API to write fully reactive applications. On top of asynchronous processing in servlets, REST services and EJBs, there is asynchronous IO, managed multithreading and CompletableFuture with its promise-like API to tackle callback hell. Several Java EE implementations, like Payara Micro, go even further and provide extensions to scale your applications in natural way.
Will include code examples and short demonstration using Payara Micro.
How to bake reactive behavior into your Java EE applicationsOndrej Mihályi
You will witness that Java EE is a modern and evolving framework and you’ll learn how it supports reactive concepts by many examples and live demonstration. The latest version of Java EE together with Java 8 add even more asynchronous API to write fully reactive applications. Several Java EE implementations, like Payara Micro, go even further and provide extensions to scale your applications in a natural way.
Source code in github: https://github.com/OndrejM-demonstrations/Reactive-CargoTracker
How to bake reactive behavior into your Java EE applicationsOndrej Mihályi
Reactive applications are flexible and robust. Reactive programming is already an established concept and there are many modern frameworks and tools which support it. You need to understand the concept in order to build truly reactive applications. But you do not need to switch from what you already know to build them. With standard Java EE you have wide range of options to add reactive behavior to new and even existing applications.
Java EE is a modern and evolving framework, which supports reactive concepts. The latest versions of JDK and Java EE add even more asynchronous API to write fully reactive applications. On top of asynchronous processing in servlets, REST services and EJBs, there is asynchronous IO, managed multithreading and CompletableFuture with its promise-like API to tackle callback hell. Several Java EE implementations, like Payara Micro, go even further and provide extensions to scale your applications in natural way.
Easily scale enterprise applications using distributed data gridsOndrej Mihályi
With the right tools, building scalable applications can be much easier than it seems. I want to show you the variety of options you get when you design applications around distributed data grids. They can become a backbone for building horizontally scalable applications, while at the same time providing flexible caching to scale up the performance vertically.
Suddenly it will be possible to tweak the applications beyond what you would expect, with very little effort, often without even rebuilding the applications. We’ll analyze what’s possible and how to do it, not only in theory but also demonstrating on an application based on Java EE, Hazelcast, and Node.js. In the end, you’ll understand the power of distributed data grids and how to use them efficiently to scale the applications in various scenarios, be it high-throughput, low-latency, microservice architecture and more.
Elastic and Cloud-ready Applications with Payara MicroOndrej Mihályi
This session will explain how to build modern and scalable applications, while efficiently adding business value. With the right tools, technical decisions can be deferred and problems can be solved according to business needs instead. Payara Micro – an open source MicroProfile-compatible runtime – provides these tools in an easy-to-use package, allowing developers to focus on getting the job done. In addition, it can be connected using a standard API to Apache Kafka or Amazon SQS for high performance messaging.
In this talk, you’ll learn how to create an architecture around all these tools to get as much flexibility as possible and be ready to deploy your applications into cloud. During a live demonstration, you’ll see how a Java EE application can benefit from dynamic clustering, MicroProfile API, distributed configuration and scalable cache built into the Payara Micro runtime.
Bed con - MicroProfile: A Quest for a lightweight and reactive Enterprise Ja...Ondrej Mihályi
Slides from the talk given at the BED conference in Berlin 2017.
Do you still think that Java EE is heavy-weight, cumbersome and doesn’t keep up with modern trends? I’ll show you that there are already production-ready enterprise and opensource solutions to bring more flexibility than the traditional Java EE servers from the past. They strive to provide lightweight and extensible runtimes to power microservices, cloud deployments and reactive architectures already. Their individual efforts are naturally followed by an open collaboration within the MicroProfile project.
I invite you to join the adventure with me and follow the quest for a new generation enterprise Java platform. We will explore what has happened recently in the world of enterprise Java and the features already provided by some interesting open-source projects. Afterward, we will discover what the Eclipse MicroProfile project is, what it can bring to you, and how you can influence it. As a core contributor in the MicroProfile project, I'll provide details about how to get started and what to expect in the near future, all illustrated by live coding and demonstrations.
Easily scale enterprise applications using distributed data gridsOndrej Mihályi
Presented at JPrime conference 2017 (jprime.io)
With the right tools, building scalable applications can be much easier than it seems. I want to show you the variety of options you get when you design applications around distributed data grids. They can become a backbone for building horizontally scalable applications, while at the same time providing flexible caching to scale up the performance vertically.
Suddenly it will be possible to tweak the applications beyond what you would expect, with very little effort, often without even rebuilding the applications. We’ll analyze what’s possible and how to do it, not only in theory but also demonstrating on an application based on Java EE, Hazelcast, and Node.js. In the end, you’ll understand the power of distributed data grids and how to use them efficiently to scale the applications in various scenarios, be it high-throughput, low-latency, microservice architecture and more.
Source code: https://github.com/OndrejM-demonstrations/scaling-with-datagrids
Article about flexible clustering: http://blog.payara.fish/flexible-clustering-with-payara-server
Hazelcast: hazelcast.com, hazelcast.org
Payara: payara.fish, payara.org
Third lecture in Java EE training series.
Covers:
- JPA entities and persistence units
- Mapping of JPA entities to SQL database
- Querying entities
- Lazy and eager loading
- Id generation
- Optimistic locking
Second lecture in Java EE training series.
Covers:
- Maven objectives
- Build lifecycle
- Dependencies and Repositories
- Plugins, profiles and configuration
- Multiple modules
- Useful plugins
- Jave EE projects with Maven
First lecture in the Java EE training course.
Covers:
- Java EE project setup
- Introduction to Maven
- Web application structure
- JSF basics
- CDI basics
Large Language Models and the End of ProgrammingMatt Welsh
Talk by Matt Welsh at Craft Conference 2024 on the impact that Large Language Models will have on the future of software development. In this talk, I discuss the ways in which LLMs will impact the software industry, from replacing human software developers with AI, to replacing conventional software with models that perform reasoning, computation, and problem-solving.
Utilocate offers a comprehensive solution for locate ticket management by automating and streamlining the entire process. By integrating with Geospatial Information Systems (GIS), it provides accurate mapping and visualization of utility locations, enhancing decision-making and reducing the risk of errors. The system's advanced data analytics tools help identify trends, predict potential issues, and optimize resource allocation, making the locate ticket management process smarter and more efficient. Additionally, automated ticket management ensures consistency and reduces human error, while real-time notifications keep all relevant personnel informed and ready to respond promptly.
The system's ability to streamline workflows and automate ticket routing significantly reduces the time taken to process each ticket, making the process faster and more efficient. Mobile access allows field technicians to update ticket information on the go, ensuring that the latest information is always available and accelerating the locate process. Overall, Utilocate not only enhances the efficiency and accuracy of locate ticket management but also improves safety by minimizing the risk of utility damage through precise and timely locates.
Check out the webinar slides to learn more about how XfilesPro transforms Salesforce document management by leveraging its world-class applications. For more details, please connect with sales@xfilespro.com
If you want to watch the on-demand webinar, please click here: https://www.xfilespro.com/webinars/salesforce-document-management-2-0-smarter-faster-better/
Exploring Innovations in Data Repository Solutions - Insights from the U.S. G...Globus
The U.S. Geological Survey (USGS) has made substantial investments in meeting evolving scientific, technical, and policy driven demands on storing, managing, and delivering data. As these demands continue to grow in complexity and scale, the USGS must continue to explore innovative solutions to improve its management, curation, sharing, delivering, and preservation approaches for large-scale research data. Supporting these needs, the USGS has partnered with the University of Chicago-Globus to research and develop advanced repository components and workflows leveraging its current investment in Globus. The primary outcome of this partnership includes the development of a prototype enterprise repository, driven by USGS Data Release requirements, through exploration and implementation of the entire suite of the Globus platform offerings, including Globus Flow, Globus Auth, Globus Transfer, and Globus Search. This presentation will provide insights into this research partnership, introduce the unique requirements and challenges being addressed and provide relevant project progress.
Essentials of Automations: The Art of Triggers and Actions in FMESafe Software
In this second installment of our Essentials of Automations webinar series, we’ll explore the landscape of triggers and actions, guiding you through the nuances of authoring and adapting workspaces for seamless automations. Gain an understanding of the full spectrum of triggers and actions available in FME, empowering you to enhance your workspaces for efficient automation.
We’ll kick things off by showcasing the most commonly used event-based triggers, introducing you to various automation workflows like manual triggers, schedules, directory watchers, and more. Plus, see how these elements play out in real scenarios.
Whether you’re tweaking your current setup or building from the ground up, this session will arm you with the tools and insights needed to transform your FME usage into a powerhouse of productivity. Join us to discover effective strategies that simplify complex processes, enhancing your productivity and transforming your data management practices with FME. Let’s turn complexity into clarity and make your workspaces work wonders!
OpenFOAM solver for Helmholtz equation, helmholtzFoam / helmholtzBubbleFoamtakuyayamamoto1800
In this slide, we show the simulation example and the way to compile this solver.
In this solver, the Helmholtz equation can be solved by helmholtzFoam. Also, the Helmholtz equation with uniformly dispersed bubbles can be simulated by helmholtzBubbleFoam.
In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I ...Juraj Vysvader
In 2015, I used to write extensions for Joomla, WordPress, phpBB3, etc and I didn't get rich from it but it did have 63K downloads (powered possible tens of thousands of websites).
AI Pilot Review: The World’s First Virtual Assistant Marketing SuiteGoogle
AI Pilot Review: The World’s First Virtual Assistant Marketing Suite
👉👉 Click Here To Get More Info 👇👇
https://sumonreview.com/ai-pilot-review/
AI Pilot Review: Key Features
✅Deploy AI expert bots in Any Niche With Just A Click
✅With one keyword, generate complete funnels, websites, landing pages, and more.
✅More than 85 AI features are included in the AI pilot.
✅No setup or configuration; use your voice (like Siri) to do whatever you want.
✅You Can Use AI Pilot To Create your version of AI Pilot And Charge People For It…
✅ZERO Manual Work With AI Pilot. Never write, Design, Or Code Again.
✅ZERO Limits On Features Or Usages
✅Use Our AI-powered Traffic To Get Hundreds Of Customers
✅No Complicated Setup: Get Up And Running In 2 Minutes
✅99.99% Up-Time Guaranteed
✅30 Days Money-Back Guarantee
✅ZERO Upfront Cost
See My Other Reviews Article:
(1) TubeTrivia AI Review: https://sumonreview.com/tubetrivia-ai-review
(2) SocioWave Review: https://sumonreview.com/sociowave-review
(3) AI Partner & Profit Review: https://sumonreview.com/ai-partner-profit-review
(4) AI Ebook Suite Review: https://sumonreview.com/ai-ebook-suite-review
Globus Compute wth IRI Workflows - GlobusWorld 2024Globus
As part of the DOE Integrated Research Infrastructure (IRI) program, NERSC at Lawrence Berkeley National Lab and ALCF at Argonne National Lab are working closely with General Atomics on accelerating the computing requirements of the DIII-D experiment. As part of the work the team is investigating ways to speedup the time to solution for many different parts of the DIII-D workflow including how they run jobs on HPC systems. One of these routes is looking at Globus Compute as a way to replace the current method for managing tasks and we describe a brief proof of concept showing how Globus Compute could help to schedule jobs and be a tool to connect compute at different facilities.
First Steps with Globus Compute Multi-User EndpointsGlobus
In this presentation we will share our experiences around getting started with the Globus Compute multi-user endpoint. Working with the Pharmacology group at the University of Auckland, we have previously written an application using Globus Compute that can offload computationally expensive steps in the researcher's workflows, which they wish to manage from their familiar Windows environments, onto the NeSI (New Zealand eScience Infrastructure) cluster. Some of the challenges we have encountered were that each researcher had to set up and manage their own single-user globus compute endpoint and that the workloads had varying resource requirements (CPUs, memory and wall time) between different runs. We hope that the multi-user endpoint will help to address these challenges and share an update on our progress here.
Field Employee Tracking System| MiTrack App| Best Employee Tracking Solution|...informapgpstrackings
Keep tabs on your field staff effortlessly with Informap Technology Centre LLC. Real-time tracking, task assignment, and smart features for efficient management. Request a live demo today!
For more details, visit us : https://informapuae.com/field-staff-tracking/
Gamify Your Mind; The Secret Sauce to Delivering Success, Continuously Improv...Shahin Sheidaei
Games are powerful teaching tools, fostering hands-on engagement and fun. But they require careful consideration to succeed. Join me to explore factors in running and selecting games, ensuring they serve as effective teaching tools. Learn to maintain focus on learning objectives while playing, and how to measure the ROI of gaming in education. Discover strategies for pitching gaming to leadership. This session offers insights, tips, and examples for coaches, team leads, and enterprise leaders seeking to teach from simple to complex concepts.
Software Engineering, Software Consulting, Tech Lead, Spring Boot, Spring Cloud, Spring Core, Spring JDBC, Spring Transaction, Spring MVC, OpenShift Cloud Platform, Kafka, REST, SOAP, LLD & HLD.
May Marketo Masterclass, London MUG May 22 2024.pdfAdele Miller
Can't make Adobe Summit in Vegas? No sweat because the EMEA Marketo Engage Champions are coming to London to share their Summit sessions, insights and more!
This is a MUG with a twist you don't want to miss.
Quarkus Hidden and Forbidden ExtensionsMax Andersen
Quarkus has a vast extension ecosystem and is known for its subsonic and subatomic feature set. Some of these features are not as well known, and some extensions are less talked about, but that does not make them less interesting - quite the opposite.
Come join this talk to see some tips and tricks for using Quarkus and some of the lesser known features, extensions and development techniques.
9. @OMihalyi
But…
• … if waiting is too long
Thread resources are wasted
Processing may halt if all
threads waiting
10. @OMihalyi
Spawn a separate thread
• Idea:
- Blocking call in a new thread
- Do something while waiting
- Retrieve results
- Fail after timeout vs. block infinitely
12. @OMihalyi
Finish in a new thread!
• Idea:
− Blocking call in another thread
− Transfer context to another thread
− No need to wait for the blocking
call
− But new thread may still be
blocked…
13. @OMihalyi
…and asynchronous calls
• Idea:
− Provide a callback
− Call finishes immediately
− Callback called in a new thread
− Finish request in the callback
− No need to wait at all
− But, is it possible?
14. Possible in Enterprise?
• New tools and frameworks
➔
High risks and costs
• Fully reactive approach
➔
High cost of development
➔
Harder to avoid and track bugs
• Advice:
➔
reactive where it’s worth it
➔
leave the door open for future
@OMihalyi
15. Java EE leaves the door open
• Established and wide-spread
− Built with resilience in mind (Transactions)
− Messaging is first-class citizen (JMS)
• Continuous improvements
− Asynchronous API, thread-management
− Scalability improvements (distributed caches & sessions)
− Portable CDI extensions
@OMihalyi
16. @OMihalyi
Asynchronous API in Java EE
• Async Servlet request completion
• Async JAX-RS request completion
• Async JAX-RS client
• Async IO in Servlet
• Async EJB calls
• Managed Executors
• WebSockets
17. @OMihalyi
Async API Example
• JAX-RS AsyncResponse @Suspended
@GET
void get(@Suspended
AsyncResponse response)
…
response.resume("OK");
18. @OMihalyi
Async API Example
• JAX-RS async client
resourceTarget
.request(MediaType.TEXT_PLAIN)
.async()
.get(
new InvocationCallback() …
19. @OMihalyi
Java EE + Java 8
• Future → CompletableFuture ?
− No, not compatible
• Callbacks → CompletableFuture
− callback triggers cf.complete()
• Pass CF as additional parameter to
complete it later
20. @OMihalyi
Complete CF in a callback
cf = new CompletableFuture<...>();
webtarget.async()
.get(new InvocationCallback() {
… cf.complete(result); …
});
cf.thenAccept(result -> …)
26. @OMihalyi
Context propagation pitfalls
• Resources can be closed prematurely
• Not everything is propagated
– transactions
• Avoid container-managed resources
– CDI Request scope
27. @OMihalyi
●
Other parts of being Reactive
• We’ve shown responsive API
• The other 3 reactive concepts:
−Resilience
−Messaging
−Elasticity
28. @OMihalyi
Payara Micro
• Application server as executable JAR
• Runs WAR apps from command line
• automatic and elastic clustering
→ spawn many micro services dynamically
→ replication using distributed cache
→ shared 60MB runtime, 40MB in heap
www.payara.fish
29. @OMihalyi
• Simple messaging and caching
@Inject @Outbound
Event<MyMsg> ev;
// handle in different JVM
void handle(@Observes
@Inbound MyMsg ev) {
… }
Payara Micro Event Bus
- events triggered on all nodes
- Asynchronous micro services
- No need for service registry
- On top of CDI events
JCache API
• Standard Java API for caching
• Distributed cache
Simple messaging and caching
30. @OMihalyi
Dynamic scaling
• Just run repeatedly
• binds to a free port to avoid port collisions
• All instances autoconnect to a cluster
− Even across network (multicast)
java -jar payara-micro.jar
--deploy app.war
--autoBindHttp
33. @OMihalyi
• Fully reactive comes at a greater cost
− Dealing with threads, hard to track origin,
communication overhead
• Don’t over-engineer, but leave doors open
• Java EE enables gradual improvement
General advice
Since application requirements changed in recent years, we went through from having tens of servers and gigabytes of data to thousands of multi processors and petabytes of data. We now want applications to be more flexible, loosely coupled from each other and scale at any factor. The idea behind the reactive manifesto is to suffice those needs, by having response, elastic, resilient, message driven applications.
Reactive means system will response in a timely manner, which will increase the usability of the application. With the help of asynchronous implementation models, the user could get partial responses and the executed code parts would not block each other for the sake of the responsiveness. It also states that the application will be resilient, meaning that application will stay responsive if any problem occurs. In order to be responsiveness, meaning that to get back to the user faster at every request, application should be elastic, it should increase or decrease its resources according to the input. That would also be the cost-effective way for implementing reactive approach. For having loosely coupled components, reactive systems favor message driven approach, which will allow non-blocking communication between the components.
Of course application do not inherently like this, since there is a good deal of traditional blocking API and they are being heavily used inside applications, such as JDBC. And monolithic architectures need to evolve in order to support reactive approach and that means time + money. It’s also hard to do reactive coding, you will be dealing with callbacks and threads spawning everywhere.
There are frameworks of course that embodies reactive approach from ground up but they are completely new frameworks like Vert.x, as a Java EE developer you should learn everything from scratch.
So in JavaEE wise, we’ll be talking about where you can introduce reactive approach into your existing code base, where it adds the most value. For that reason, we converter the famous cargo-tracker application, into reactive cargo-tracker ;)
When dealing with incoming requests, the traditional approach is – one thread per request, all is sequential, waiting for slow resources like DB or external services adds to the request processing time.
Just a transition slide to next slide – next slide automatically appears after 10 seconds.
But waiting is not bad, if we can afford it. It is simple, as sequential is easier than parallel, and it is thread-safe. And we can afford it in many scenarios. Thus additional complexity to solve blocking calls is not required in many cases.
At this point – a warning finger is raised with But…, and a small pause to watch the video.
If there are too many slow blocking calls involved, often many resources (threads, CPU) are being wasted during waiting.
And what if all threads are waiting? You may guess – the system is far from being responsive. The application may halt processing new requests and even crash under high load. Being responsive is one of the key aspects of the Reactive Manifesto, and if our application fails to meet that too often, it becomes unusable and therefore not suitable for production. So let’s look at how the responsiveness can be improved.
How we can improve on this? Let’s introduce more threads, so that we can continue processing something else in the original thread while waiting.
`Future`API supports this concept in Java.
We gained more control over waiting. Now, we can decide not to wait for a result after timeout and release resources with an error response. But users don’t like error messages, do they?
There are also technically drawbacks to this approach. The API may become complex, requiring checking for results iteratively, or falling back to waiting infinitely once further processing depends on the result.
It is also not efficient to resources. It even consumes more threads now, just to give us more control over waiting.
If we let any thread to finish the response, there’s no need to wait for threads to finish. We may simply release threads as the work is finished, and the task that finishes last will complete the request. We only need to pass the context of the request between threads.
But since the blocking call is still involved, there is always at least one thread being blocked by it. We need still need to add something more to the recipe to utilize resources effectively.
Ideally, we should not block any thread while waiting for a resource. We only need to handle the response from the resource in another thread. The catch is that the API to access the resource must provide a non-blocking call, which accepts a callback.
So the recipe for making the application responsive and resource efficient is:
- ability to transfer the request context to another thread
- asynchronous API to avoid blocking
And the question is – how Java EE supports these 2 concepts?
Is it possible to build reactive applications in enterprise environment? And is it worth it?
Although Java EE is also suitable in other areas, it already provides a stable and robust platform to build applications in the enterprise. Building new enterprise applications on top of completely new frameworks introduces a great risk. But the real problem is that majority of enterprise applications are not new, and rebuilding them from scratch using a new platform is not even an option.
On the other hand, rebuilding whole application to meet reactive expectations has its drawbacks too. Reactive approach is not natural for many developers and is not straightforward in most languages. Furthermore, the asynchronous aspect of it brings new challenges to making sure that the code is correct and to track and fix bugs.
Although Java EE might not be the best platform to build fully reactive applications, it provides enough means to significantly improve reactiveness of existing applications and build new reactive applications with the investment in learning a completely new framework. An important promise of Java EE is that it makes it simple and fast to build traditional enterprise applications, while leaving the door open for future enhancements and refactoring step by step to improve its reactiveness You can thus continue later with making only critical parts of your applications reactive and improve other parts later.
Established and improving platform
→ small costs of upgrade or redesign
→ simplifications (EJB3, CDI, JMS 2.0 simplified API)
Improvements of the application where needed
→ turn many synchronous API to async
→ split the task into multiple threads - managed executor
→ easily extend with CDI extensions to provide custom reactive features
Java EE supports passing of a request context and finishing the response in another thread:
- Servlet
- JAX-RS endpoint
For example, Servlet IO and JAX-RS client API provide asynchronous calls with callbacks when a response from a resource is ready.
But the truth is that this is not possible with every Java EE API. In that case, you need to resort to wrapping a blocking call in a separate thread. But keep in mind that you should get it from a separate thread pool so that it does not affect other processing while being blocked.
Async EJB calls provide a simple way to run tasks in separate threads.
Managed executors are exactly what you need for a finer-grained control over scheduling tasks in separate threads, even in various thread pools.
Finally, WebSockets are convenient to build highly responsive frontends, which are updated as soon as possible and not only after all the data is available.
The JAX-RS 2.0 specification has added asynchronous HTTP support via two classes. The @Suspended annotation, and AsyncResponse interface.
Having AsyncResponse instance passed as a parameter to the method states that the HTTP request/response should be detached from the currently executing thread and that the current thread should not try to automatically process the response.
AsyncResponse is a callback object, meaning that calling resume method will cause a response to be sent back to the client and will also terminate the HTTP request.
For the client side it’s also possible to introduce async calls, with the help of .async() method invocation and the instance of InvocationCallback that we are providing enables the way to interfere with the server response. Here InvocationCallback is a callback implementation as you would guess, which offers methods named: completed() and failed().
Where Java EE provides the means, Java 8 makes it easier to write reactive code, mainly with 2 new additions
- lambdas, which make it very easy to build callbacks
- CompletableFuture, which makes it easy to handle asynchronous calls and chain callbacks
But how to combine them effectively, as Java EE is built on top of Java 7 only?
Ideally, CF or its interface counterpart CompletionStage could be used instead of Future. But that would require support in Java EE, no sooner than in Java EE 8.
Therefore we need to adopt another approach.
We need to create a CF ourselves and pass it to an asynchronous call, either within the callback object, or as a parameter to an asynchronous EJB method. The asynchronous call will then call either cf.complete() or cf.completeExceptionally() after the call is finished.
Why is CF so much better than Future? Chain of callbacks executable in various threads, instead of just waiting for a thread to complete. It is possible to chain CF themselves using thenCompose, making it easy to chain multiple asynchronous calls.
Furthermore provides a standard way to complete the future or throw and exception.
-ondrej -mert
-ondrej -mert
-ondrej -mert
We usually want to access the same resources during request processing. A request spans multiple threads and this causes some problems with the traditional Java EE. References to resources are bound to a thread and have to be transferred to subsequent threads.
When new threads are provided using the managed executor service, it automatically passes the context to the new threads.
If threads are created using plain Java SE, they context needs to be transferred manually, using the ContextService. In a simple scenario, we can easily wrap a lambda within a contextual proxy using appropriate functional reference. The proxy will then transfer the thread context before each method call.
Remember, the contextual proxy has to be created in a managed thread. Its methods can be called in unmanaged threads. It would not work if we created the proxy inside a callback.
We usually want to access the same resources during request processing. A request spans multiple threads and this causes some problems with the traditional Java EE. References to resources are bound to a thread and have to be transferred to subsequent threads.
When new threads are provided using the managed executor service, it automatically passes the context to the new threads.
If threads are created using plain Java SE, they context needs to be transferred manually, using the ContextService. In a simple scenario, we can easily wrap a lambda within a contextual proxy using appropriate functional reference. The proxy will then transfer the thread context before each method call.
Remember, the contextual proxy has to be created in a managed thread. Its methods can be called in unmanaged threads. It would not work if we created the proxy inside a callback.
-ondrej
There’s more to being reactive than just responsiveness.
We can continue to extend our analogy with the Kung-fu master to explain the other 3 concepts.
- we need to be resilient to problems and any damage received from our enemies and keep fighting -&gt; Resilience
- when fighting together with our allies, we shout for help but cannot afford to wait for it and need to continue fighting. The help will come eventually. -&gt; hence Messaging for communication
- and of course Elasticity – it would be great if we could clone ourselves to fight more enemies, wouldn’t it?
Java EE traditionally offers means to ensure resilience using transactions and clustering; and provide messaging, mainly by the JMS. In a bigger picture, It is usually extend by additional infrastructure to improve resilience and elasticity, e.g. by load balancing and service discovery. But this is not enough. We often need to resort to additional features of a specific application server to complete what is missing. An example of an application server providing more support for building and running reactive applications, is Payara Micro.
So Payara Micro enables you to run war files from the command line without any application server installation. It is small, around 70mb and you can just execute it by using java –jar. You can deploy a web application archive through the command line and with the hazelcast integration each Payara Micro instance that will be spawned will automagically cluster with other Payara Micro processes on the network, giving you an automatic and elastic clustering configuration.
If you haven’t tried our Micro before, give it a try we have a good deal of resources on payara.fish, you can even execute Micro on your Raspberry PI…!
So dispatching events across JVM is simple as using CDI’s outbound event mechanism where you wrap your instance type with Event and then fire it in order to have it observed in the handle method given below. One thing to be noted here is: this model executes as the topic approach of JMS.
So Event Bus of Payara Micro handles the events on any distributed node, which brings asynchronous model to the implementation. Yay! We have reactive micro services now right? There is no need for an UDDI / Service Registry definition and these all can be implemented with the help of 2 qualifiers on CDI events, @Outbound and @Inbound.
Payara Micro uses Hazelcast’s distributed executor in the background to achieve this.
In order to spawn a new server, just run java –jar payara-micro.jar and with – deploy parameter specify your war application and with –autoBindHttp parameter we will enable the application server to auto-bind to an HTTP port to prevent collisions.
All spawned micro instances will auto-connect to a cluster, even across networks.