Http 1.0 versus http 1.1 protocol

Http 1.0 versus http 1.1

Http 1.0 is based on thread per request while http 1.1 is based on thread per connection.

What does that mean?

When a user send a request from browser Web Container allocate the request to a thread available in thread pool. Once response is returned ,that thread is released and is made available is pool again . This is http 1.0

In case of http 1.1 , This thread is not released but kept assigned to the user connection . So if user further send request , a new thread is not requested from threadpool instead same thread picks up that request and process that. This is http 1.1 . So here thread is not just one request scoped but stay alive for all connection duration.







Which is good ?

Won't it be a good idea to keep the thread allocated to a connection instead of just thread. In case of thread per request ,once one request is processed , thread is released So for next request http again need to negotiate and may need to wait if all threads are engaged and no ready thread is available in pool. waiting time can vary request to request based on availability of thread in pool. So overall response time for multiple requests would be very inconsistent and user experience can be very unpleasant.

Now let's talk about another scenario. There can a peak load time when thousands of user's areare accessing the website and to server those requests efficienlty it would require many threads . each connection need one thread in thread per connection scenario or once fixed number of threads in thread pool are exhausted next request will have to wait till a thread is available in the pool. So that would require too many system resources and will consume high memory

Moreover a thread will keep on waiting between two user requests. In that idle time thread could be used to do useful task for some other request.

So depending upon scenario you are dealing with there are pros and cons of both http 1.0 and http 1.1 

To remove all these bottlenecks a new approach is followed now a days. asynchronous call with thread per request model. 




 
In this approach
Thread keeps on doing useful task all the time . Anytime a processing consumes time, thread leaves that there and create asyncContext in application context. Once process is done with the current task it triggers an async even and container assign available thread to process further . Thus asynchronous approach is based on call back and a-sync events based techniques . Servlet 3.0 follows the same approach . Threads don't have to keep themselves in idle state while process is blocked for some resource like connection , I/O etc instead java SE 7.0 NIO is used to keep I/O calls non blocking.

 

Top Java News- September 18 ,2013

Java Developer Here Is The City Java Developer required at a leading investment bank in the city offering fantastic ... My client are looking for a Java Developer from a Computer Science (or ... See all stories on this topic »
As many as 80% of the world's PCs may be running exploitable Java ... GMA News As many as four out of five PCs running Microsoft's Windows are running outdated versions of Java and may be vulnerable to attack, a security vendor warned. See all stories on this topic »
Darkleech campaign targets Java to spread Reveton ransomware V3.co.uk The Darkleech campaign responsible for compromising thousands of websites has resurfaced, targeting Java and Adobe vulnerabilities to spread the Reveton ... See all stories on this topic »    Automation Tester | C# or Java | Test Automation Frameworks Here Is The City My client is a top financial services vendor in London and are urgently in the market for several skilled Automation Testers to join their team. My client builds ... See all stories on this topic » Tech Lead (JAVA) Emirates 24/7 Tech Lead (JAVA) PRONTO SOFTWARE. Candidate Requirements • Degree in information Technology; • At least 4 years of experience in software ... See all stories on this topic » JAVA Developer Bizcommunity.com We will only be getting back to applicants that meet all of the above requirements. Should you not receive a response from us within 2 weeks you can deem your ... See all stories on this topic » Making Java Groovy: JavaRanch this week | Stuff I've learned ... Ken Kousen This week Making Java Groovy is the featured book at JavaRanch, where I've been a member for many years. JavaRanch is yet another of Kathy Sierra's (and ... Stuff I've learned recently...

CQ5 Author or Publisher instance is down due to OutOfMemoryError.

Overview

OutOfMemoryError can occur any time in heap due to insufficient heap memory being available for new Java objects creation. CQ Author/Publisher will eventually crash due to OutOfMemoryError and would need to be restarted.

  

Issue

CQ5 Author or Publisher instance is down due to OutOfMemoryError.

Resolution

1.     

2.    Access all publisher and author instances and note which all instances are not responding. 

 

3.      For all instances not responding Access CRX error logs Note down which all instances are throwing OutOfMemoryError. In error log OutOfMemoryError can be searched by searching file content for string ”OutOfMemoryError”

4.    For every publisher instance throwing OutOfMemoryError follow the below steps: 

5.      Execute Datastore Garbage Collection operation in configuration repository.  To execute this operation visit http://:/system/console/memoryusage for the publisher instance and click on runDataStoeGarbageCollection operation as shown below.

6.    This should free up some memory.

7.    Stop the server by executing

8.    Start the server by executing

9.    Access the publisher instances and note which all publishers are not responding.

10. If all publishers instances are responding well issue is resolved.

Interface Segregation Principle(ISP) - Java design principals , OOPS design principals ,Object oriented design principals , How to design interface in java

Interface Segregation Principle stats that, a client should not implement an interface, if it doesn't use that.

What exaclt does that mean ?

Let's understand this

Consider there is one interface Travel

Travel has two methods

travelbyBus()

travelByTrain()

Now there is one class Passenger . Passenger will always travel by bus .
 
if Passenger class implements Travel interface

Passenger implements Passenger {

travelbyBus(){
}

travelByTrain(){
}

}

It is forced to implement both the methods travelByBus() and travelByTrain() , thought Passenger has nothing to do with travelByTrain().


Now lets read the principal again

Interface Segregation Principle stats that, a client should not implement an interface, if it doesn't use that.

Client Passenger should not be forced to implement travelByTrain() method as it never needs it.








Here comes the Interface designing best practice .

An interface design should be very thoughtful. It should always take in consideration all its possible clients and should always make interface design client friendly.


So could that be achieved?

 Instead of creating one interface for both methods , two separate interfaces could be designed

like :

BusTravel{

travelByBus();
}


TrainTravel{

travelByTrain();
}


Passenger class can implement BusTravel interface and will not be forced to implement anymore method.




Thus Interface Segregation Principle(ISP) basically recommend to design the interfaces taking in consideration holistic ststem and all poosible clients.

Liskov Substitution Principle (LSP) : Design Principal , Java Design Principal

Liskov Substitution Principle (LSP)

According to Liskov Substitution Principle, methods or functions which uses super class type must be able to work with object of sub class without any issue".


Let us understand this with an example 

 

Public class Cat extends Animal {
}


public class Animal{
}


Public class TestLSP{


public void execute(Animal animal){

}
public void executor(){

Animal animal =new Animal();
execute(animal);
 
Cat cat = new  Cat();
execute(cat);
}





So we are able to call execute method from executor method by passing Animal class instance as well as Cat class instance .

 Cat class extends Animal So is subclass to Animal class. 

Thus Animal class parameter expected in executor method works well with Animal as well as subtype Cat type of instance . that's what LSP says.