Flexbox

https://css-tricks.com/snippets/css/a-guide-to-flexbox/

Bootstrap

https://www.freecodecamp.org/news/learn-bootstrap-4-in-30-minute-by-building-a-landing-page-website-guide-for-beginners-f64e03833f33/

Netflix OSS - Service Discovery (Eureka) Circuit Breaker (Hystrix) Intelligent Routing (Zuul) Client Side Load Balancing (Ribbon)

http://salerno-rafael.blogspot.com/2016/08/spring-cloud-netflix-how-works-service.html

Spring Cloud Netflix - How works Service Registration and Discovery

Spring Cloud has a full stack for micro services. The main objective of the spring cloud is to provide a complete integration between Spring Boot and Netflix OSS project, where simple annotation is possible have some components used by Netflix running in your environment

Some pattern provided by Netflix OSS that Spring Cloud provides: 

• Service Discovery (Eureka)
• Circuit Breaker (Hystrix)
• Intelligent Routing (Zuul)
• Client Side Load Balancing (Ribbon)

In this post will talk about service discovery, showing the concept and how it is possible with a few annotation have the default working on a project with Spring Boot.

Service Discovery is one of the key tenets of micro service based architecture. Trying to hand configure each client or some form of convention can be very difficult to do and can be very brittle. Eureka is the Netflix Service Discovery Server and Client. The server can be configured and deployed to be highly available, with each server replicating state about the registered services to the others.

Why Use Service Discovery?

Let's imagine we have many services dynamically distributed on the network. Where instances of services dynamically change because of auto-scaling, failures, upgrades, and we have no control of IP addresses, the name of the instance.

In this situation the simplest would be if the service tell the server or other services where it is and if it is available.

This is how the discovery service works, the service entered in the network and register on a server to make it available for the use of some other service.

The pattern that will be addressed in this post will be The Server-Side Pattern Discovery.

Where customers know where the server is and send to the server that is available.

Registering:

When a client registers with Eureka, it provides meta-data about itself such as host and port, health indicator URL, home page etc. Eureka receives heartbeat messages from each instance belonging to a service. If the heartbeat fails over a configurable timetable, the instance is normally removed from the registry.

Status Page and Health Indicator:

The network location of a service instance is registered with the service registry when it starts up. It is removed from the service registry when the instance terminates. The service instance’s registration is typically refreshed periodically using a heartbeat mechanism.

Eureka’s Health Checks:

By default, Eureka uses the client heartbeat to determine if a client is up. Unless specified otherwise the Discovery Client will not propagate the current health check status of the application per the Spring Boot Actuator. Which means that after successful registration Eureka will always announce that the application is in 'UP' state. Enabling Eureka health checks can alter this behavior, which results in propagating application status to Eureka. As a consequence every other application won’t be sending traffic to application in state other then 'UP'.

Server code:

Client 1 code:

                         defaultZone is the Eureka service address

Tomcat port to client 1

Client 2 code:

The same of the client 1 but in other port

        Tomcat port to client 2

STEPS TO RUN:

1.The first step is run server:

Will be available on http://localhost:8761 and will be showed some information’s and a screen with the instances available.

2.The second step is run client, this client will be registered in the server:

Now in the server is possible see the instance registered:

 

3.The third step is run the second client:

Now in the server is possible see the new instance registered:

all instances already registered:

 

In this links is possible see some information about instances:

• Eureka’s information like IP address, App Name, Status, port ...
• http://localhost:8761/eureka/apps 
• Service’s Environment 
• http://localhost:8761/env  
• Instance’s Environment 
• http://localhost:8081/env 
• Service health 
• http://localhost:8761/health 
• Instances health
• http://localhost:8081/health 

Health information image:

 

Lombok

https://projectlombok.org/features/GetterSetter

Micro-FrontEnd

https://medium.com/bb-tutorials-and-thoughts/6-different-ways-to-implement-micro-frontends-with-angular-298bc8d79f6b

https://medium.com/bb-tutorials-and-thoughts/how-to-implement-micro-frontend-architecture-with-angular-e6828a0a049c

• Iframes
• Through NGINX
• Web Components/Angular Elements
• Angular Libraries
• Monorepos
• Customized Orchestrator

java.lang.OutOfMemoryError: Metaspace

https://plumbr.io/outofmemoryerror/metaspace
https://plumbr.io/outofmemory-metaspace

So if you were familiar with PermGen then all you need to know as background is that – whatever was in PermGen before Java 8 (name and fields of the class, methods of a class with the bytecode of the methods, constant pool, JIT optimizations etc) – is now located in Metaspace.

As you can see, Metaspace size requirements depend both upon the number of classes loaded as well as the size of such class declarations. So it is easy to see the main cause for the java.lang.OutOfMemoryError: Metaspace is: either too many classes or too big classes being loaded to the Metaspace.

Classloader Leak

A classloader leak happens when an application is redeployed, but there are lingering instances of the previous deployment’s classes left. These lingering instances prevent their Classes from being garbage collected, which, in turn, prevent the classloaders and all the classes held therein from being collected, too. Here’s an example of that situation:

Apparently, the application starts a thread that cleans up connections. As noble of a goal as it is, the application does not stop the thread on un-deploy, so it keeps hold of the classloader. Cleanup threads and Timer threads are by far the most common reason for the leaks. A simple way of fixing this issue would be to add a shutdown hook by implementing a ServletContextListener:

public class CleanupCleanup implements ServletContextListener {
  @Override
  public void contextDestroyed(ServletContextEvent sce) {
    // Stop the cleanup thread
  }

  //...
}

Java + HTTPS: Unable to Find Valid Certification Path to Requested Target

https://myshittycode.com/2015/12/17/java-https-unable-to-find-valid-certification-path-to-requested-target-2/

https://www.baeldung.com/java-import-cer-certificate-into-keystore

https://stackoverflow.com/questions/43188589/what-is-the-difference-between-keytool-commands-import-and-importcert/43188724

From this documentation keytool - Key and Certificate Management Tool, the Changes section at the end of the page says :

Renamed commands:

-import, renamed to -importcert

The keytool has many options but the one we're interested in is importcert which is as straightforward as its name. Since there are usually different entries inside a KeyStore, we'll have to use the alias argument to assign it a unique name:

> keytool -importcert -alias baeldung_public_cert -file baeldung.cer -keystore sample_keystore
> Enter keystore password:
...
> Trust this certificate? [no]:  y
> Certificate was added to keystore