The topic Concurrency is and always will form one of the integral part of any programming language, be it Java, Groovy, Scala etc.
What I have always felt, that this thing is one of the key factors in determining how powerful the programming language is and at the same time whenever we come across this term, the thing which comes to our mind is:
Yes!!!! To me, the topic Concurrency be it in any language, at first it becomes difficult for me to get the ideas behind all the concepts, but as I keep on learning and keep on solving puzzles then things turns out to be more and more intersting and engaging.
So I always consider Concurrency to be a rivetting theme.
Now, the Concurrency in Java using Thread model which we all have experienced more or less, differs well with the natural human sense for parallelism.
Now Why Concurrency is becoming an integral part of any computing that we do?
Beacuse due to advent and fast propagation of MULTICORE CPU's, which is almost a commonplace routine nowadays.
So It is now high time that we should immediately embrace and ratify those means which will not respect the sense of parallelism that we create in our brain but also mental models of Concurrent systems interactions.
Propitiously Groovy replenish such awesome features.
The Concurrency traits that Groovy comes up with are as follows:-
I tried to explore some of these splendid concepts and I am really Impressed!!!!!. Thanks to GPars and Groovy.
I will share my experience with some code blocks which I have followed to find out how these elements work.
Keep a close WATCH on this space for something really interesting......
1) Inspect the Request Body at the Filter (as sent by the POST method) .
2) Setting a new Request Body depending on some Business Rules, i.e. either altering the existing request body and setting a new request body for the following filters or Resource Actions.
3) Depending on some error condition, to stop the request from travelling furthur i.e. into following filters or ResourceAction and setting the response body.
Before elaborating on all the above mentioned points let me recapitulate some of key gServ Control Flow points, which I already have described in my previous blogs CONTROL FLOW that:
When an incoming request arrives, the GServHandler's handle(HttpExchange) method gets called.
This method mainly does the following things:
1) Creating of the RequestContext from already available GServConfig with the help of
new GServFactory().createRequestContext
2) Finding all the registered filters from the GServConfig that matches the Request Action.
3) Executing Filters with the help of FilterRunner
4) And if the processing for the Filters is fine then forwarding the request to ResourceAction for processing else closing the RequestContext after writing the response to the outputstream.
The code block for the filter is:
def beforeFilter = ResourceActionFactory.createBeforeFilter "bookBeforeFilter3", "POST", "/data/book", [:], 5, {requestContext, data ->
log.info " ********** I am Done!!!!!! *********** for requestContext: ${requestContext.getClass()} and Data ${data.getClass()} \n\n Data MetaClass ${data.metaClass}"
def offset = 0
def error = true
def byteArr = new byte[1024]
log.info "**** Size: ${data.size()}"
InputStream inStream
def byteArrayOutputStream = new ByteArrayOutputStream();
def result = '{"id":"11", "name":"GROOVY IN ACTION 2nd EDITION"}'
byteArrayOutputStream.write(result.getBytes())
byteArrayOutputStream.close()
inStream = requestContext.getRequestBody()
//IOUtils.copy(inStream,byteArrayOutputStream)
def byteArrayInputStream = new ByteArrayInputStream(byteArrayOutputStream.toByteArray())
def errorStream = new ByteArrayOutputStream()
errorStream.write("There is an error so Redirecting.....".getBytes())
errorStream.close()
def count = inStream.read(byteArr, offset, byteArr.length)
while(count > 0)
{
log.info "%%%%%% The Data Read Count is $count"
offset += count
log.info new String(byteArr)
count = inStream.read byteArr, offset, byteArr.length
}
inStream.close();
if(error)
{
/**
* In case of any error we are not forwarding the
* request to any following filters or Resource Action,
* Rather we can set the Response Body or Response Headers
* and at the end close the RequestContext
*/
log.info "=========== Since error was detected so closing the RequestContext $requestContext ============"
/**
* The Below lines really describes the Magic of Groovy...
* I'm imprrrrressed....
*
*/
requestContext._responseBody = errorStream
requestContext.close()
}
else
requestContext.setRequestBody byteArrayInputStream
requestContext
}
Inspect the Request Body at the Filter (as sent by the POST method)
Now from the above code we can see that the parameters to the closure of the filters (which is the Request Handler for this After Filter) are:
1) requestContext (Type is RequestContext and the actual implementation being RequestContextWrapper)
2) data (Type is List and implementation being ArrayList)
Now we can get the Request data from both of them, for the first option with the help of getRequestBody() which we have done here, or from the data which is an ArrayList, from the first element of this ArrayLisy which is of Type InputStream(FixedLengthInputStream), but the catch is once we read the InputStream with any of the practices as described above, we cannot read it again (as java.io.IOException: Stream is closed), so after reading if we close the inputstream and forward the request, then the next entities in the control flow will not be able to fetch the data from the InputStream.
so we did the following:
def byteArrayOutputStream = new ByteArrayOutputStream();
def result = '{"id":"11", "name":"GROOVY IN ACTION 2nd EDITION"}'
byteArrayOutputStream.write(result.getBytes())
byteArrayOutputStream.close()
.........
........
def byteArrayInputStream = new ByteArrayInputStream(byteArrayOutputStream.toByteArray())
................
.................
requestContext.setRequestBody byteArrayInputStream
Here we have created a new Input Stream and set it within the Request Body.
The second point i.e. Setting a new Request Body is also being covered here.
Stopping the request from travelling furthur
For this we have created an error flag, and an error InputStream and then we have closed the current RequestContext after the setting the desired response within ResponseBody
def error = true
..........
.........
def errorStream = new ByteArrayOutputStream()
errorStream.write("There is an error so Redirecting.....".getBytes())
errorStream.close()
......................
......................
if(error)
{
/**
* In case of any error we are not forwarding the
* request to any following filters or Resource Action,
* Rather we can set the Response Body or Response Headers
* and at the end close the RequestContext
*/
log.info "=========== Since error was detected so closing the RequestContext $requestContext ============"
/**
* The Below lines really describes the Magic of Groovy...
* I'm imprrrrressed....
*
*/
requestContext._responseBody = errorStream
requestContext.close()
}
We have also introduced a Custom Converter within :
/**
* Custom Converters - To convert Request Body (JSON format here)
* to the expected Object Type
*
*/
def server = gserv.plugins{
plugin ( 'compression', [:] )
plugin ('cors',[:])
}.http {
........
........
def converter = conversion(Book.class){ instream ->
def data = new JsonSlurper().parse(instream)
new Book(name: data.name,
id: data.id,
author: data.author,
price: data.price,
sellers:data.sellers,
authorAddress:data.authorAddress,
repo:data.repo)
}
}
This Custom converter converts the input JSON into Book type as expected by:
post "/book", onlyIfAccepts('text/json'), /*onlyIfHeader('Accept-Encoding',"gzip"),*/ {Book book2 ->
log.info "!!!!!!!! The Resource Action Delegate is ${delegate.getClass()}"
log.info " The POSTED data is:$book2"
log.info "Sleeping Thread....."
//sleep(20000);
def onlineRepo = new OnlineRepo(id:"GITHUB",repoURL:"http://github.com/gServ")
def address1 = new Address(building:"CHURNI",street:"PAS",city:"Kol",country:"India",zip:222334)
def address2 = new Address(building:"CHURNI2",street:"PAS2",city:"Kol2",country:"India2",zip:222334)
def address3 = new Address(building:"CHURNI3",street:"PAS3",city:"Kol3",country:"India2",zip:555334)
def book3 = new Book(name:"Groovy In Action 2nd Edition",id:"11",author:["Gordon","Dickens"],price:12.34,sellers:["seller1":"pearson","seller2":"Tata Mc Graw"],authorAddress:[address1,address2,address3],repo:onlineRepo)
def jsonOutput = JsonOutput.toJson(book3)
log.info "The JSON OUPTPUT is :$jsonOutput"
log.info "Waking Up and Pocessing......"
//book = new Book(name:"Groovy REST IN Action",id:'ISBN:9001',author:'Gordon Dickens',price:120.89)
responseHeader "content-type", "application/json"
write book2.toString().bytes
}
So this is in short about filters in gServ.
From the all our discussions and analysis on GServ we can say, that for each and every element in this framework, be it Resource, ResourceAction, Filters, ServerInstance, there is a delegate which does all the configuration and so that GServconfig can be populated and when the request arrives, then based on URL, Method, Parameter matching we execute those elements with the help of some Runner elements like for Filter there is FilterRunner, for ResourceAction there is ActionRunnner etc.
Please share your valuable comments and Suggestions.
In this post we will see how the GServConfig i.e. the config object gets constructed, followed by Control flow for Incoming Requests.
** GServInstance.start(<<PORT NUMBER>>). This method creates the HttpServer and registers the GServHandler (created in Step 3.1) with the context root "/". The GServHandler which extends HttpHandler acts like controller after it gets registered.
Along with this some init Filters also gets registered and stored in GServConfig, so that when the filters gets invoked from GServHandler.handle(HttpExchange) method, then these init filters also gets executed.
Remember the context root being "/".
So for any incoming requests, the HttpHandler’s handle(HttpExchnage) gets invoked.
The HttpExchange class encapsulates a HTTP request received and a response to be generated in one exchange. It provides methods for examining the request from the client, and for building and sending the response.
So when the incoming request arrives the HttpExchange instance along with the GServConfig object (passed in Step 3) to create the GServ RequestContext, which is then passed along for invoking filters, plugins, Actions for a particular Request.
Please note, the depicted control is an overview of my understanding of gServ.
There can be Gap between my understanding and the actual flow. Please share your views and feedback.
If I am wrong or misunderstood some part of the gServ architecture and the control flow, I apologize for that and please correct me in that case.
I thought of sharing my idea about gServ because I thought that such effort may help us in knowing this awesome Groovy framework in a better way.
That’s it and until next time Keep Coding and Keep Contributing.
A short while ago while I was exploring Spring HATEOAS , which is gradually becoming one of my dearest Spring modules and which I will surely explore furthur, I was thinking whether Groovy provides any such Rest framework .
And the answer I found is "YES" and it is known as gServ .
Though there is not too much documentation for it at present what whatever I can find from GITHUB along with my own findings, I will share it with you.
Before I start I must say that the GITHUB really helped me a lot to understand gServ features and all its setup related activities.
Lets start Now!!!
So the first question that comes to our mind that why gServ. We have such a robust Spring Rest features along with Spring HATEOAS module, what is more there in gServ that will interest us.
The gServ traits are as follows:
1) It is container free. Yes you heard it right!!!! the Rest Services can be deployed using HttpServer.
2) It serves static files.
3) It provides Plugins and HATEOAS support.
4) It has got support for CORS (Cross Origin Resource Sharing).
5) Provides Compression and ETag support and others.
Along with all these above mentioned features, we also need to get acquainted with some terms, specific to gServ before we proceed furthur.
Like:
1) gServ Resource.
2) gServ Resource Action.
3) gServ Server Instance.
4) gServ Server Config etc.
Lets Describe all of these with referenes to Code.
Below is a small piece of code block containing basic gServ features.
@SpringBootApplication
@Slf4j
class RestApp {
static main(args)
{
def book
def gserv = new GServ()
def bookResource = gserv.resource("/data"){
log.info "!!!!!!!! The Resource Delegate is ${delegate.getClass()}"
def resourceAction = post "/book", onlyIfAccepts('text/json'), /*onlyIfHeader('Accept-Encoding',"gzip"),*/ {
log.info "!!!!!!!! The Resource Action Delegate is ${delegate.getClass()}"
book = new Book(name:"Groovy REST IN Action",id:'ISBN:9001',author:'Gordon Dickens',price:120.89)
responseHeader "content-type", "application/json"
write book.toString().bytes
}
log.info "@@@@@@@@@@@@@ The Resource Action is ${resourceAction.getClass()}"
get "/bookNoEnc", onlyIfAccepts('text/json'), onlyIfHeader('Accept-Encoding',"gzip") , {
log.info "The Request Context class is1111: ${requestContext.class}"
book = new Book(name:"Groovy REST IN Action 2nd Ed",id:'ISBN:9001',author:'Gordon Dickens',price:125.89)
write book.toString().bytes
}
}
log.info "##### The BookResource is $bookResource #####"
def beforeFilter = ResourceActionFactory.createBeforeFilter "bookBeforeFilter3", "POST", "/data/book", [:], 5, {requestContext, data ->
log.info " ********** I am Done!!!!!! *********** for requestContext: ${requestContext.getClass()} and Data $data"
null
}
def server = gserv.plugins{
plugin ( 'compression', [:] )
plugin ('cors',[:])
}.http {
/*weakETag("/data/bookNoEnc"){ requestContext, byte[] data ->
Encoder.md5WithBase64(args.join('//').bytes)
}*/
log.info "!!!!!!!! The Http Server Delegate is ${delegate.getClass()}"
before "bookBeforeFilter2", "/data/book", "GET", [:], 4, {requestContext, data -> log.info "*********** ${requestContext.class} \n The data is $data"}
before "bookBeforeFilter1", "/data/book", "GET", [:], 4, {requestContext, data ->
log.info " ********** I am Done..... *********** "
requestContext
}
log.info "***** ${bookResource.basePath}"
log.info "***** ${bookResource.linkBuilder}"
addFilter beforeFilter
resource bookResource
}.start(9000)
log.info "The Server is: ${server.class}"
}
}
The above mentioned code block do not provide comprehensive coverage of the gServ features but will help us to get some idea regarding how gServ acts and all the contituent participants that makes gServ interesting.
1) gServ Resource
At the beginning of the above code block we can see that we have instantiated a class GServ. This is heart and soul of the gServ framework.
when invoking resource() on the GServ instance by passing the root path and the closure we create the gServ Resource.
Within Closure we pass the sub-elements which constitute the gServ Resource Actions.
The delegate of the closure is ResourceDelegate. This class with the help of the inherited behaviour of the trait (i.e. ResourceFn)
provides support.
A Resource in gServ can be considered as an entity on which we want to perform actions, like fetching info (GET), altering (PUT), Creating new Resource (POST), deleting a resource (DELETE) etc. Each gServ resource is associated with a basepath which is here "/data"
2) gServ Resource Action
One of the element as passed in the GServ.resource() method's closure is:
post "/book", onlyIfAccepts('text/json'), /*onlyIfHeader('Accept-Encoding',"gzip"),*/ {
log.info "!!!!!!!! The Resource Action Delegate is ${delegate.getClass()}"
book = new Book(name:"Groovy REST IN Action",id:'ISBN:9001',author:'Gordon Dickens',price:120.89)
responseHeader "content-type", "application/json"
write book.toString().bytes
}
This is the Resource action.
A Resource action is the Request Handler for a particular path/query/method combination, i.e. this resource action will handle requests having HTTP method POST, for the path "/data/book" (prepending the root/base path), and with the Request Header "Accepts" having value 'text/json'
The Delegate to the closure passed to the Resource Action is HttpMethodDelegate.
Each Resource Action can refer to the RequestContext from within the closure. The RequestContext is the object which is created by GServHandler when a request arrives for a particular endpoint for a particular path/query/method combination and which contains the request related details and we can also set response headers or fetch related info from this object. It has lot of other utilities the details can be checked out from the official documentation. It is really great out there.
So within the Request Action Closure we define the processing logic corresponding to the path/query/method combination and along with that decide on the response format (In the above example we have simply returned the dummy response as bytes) and set response headers if required and do other stiffs.
In the above code Block we have also defined some BEFORE filter for a particular path/query/method combination.
def beforeFilter = ResourceActionFactory.createBeforeFilter "bookBeforeFilter3", "POST", "/data/book", [:], 5, {requestContext, data ->
log.info " ********** I am Done!!!!!! *********** for requestContext: ${requestContext.getClass()} and Data $data"
null
}
Now that we have Resource, Resource Action, Filters in place we need to bring all of these components into Action. But the question arisis who will integrate all these components together and serve the requests.
gServ Server Instance.
The GServInstance comes to the rescue.
We create that instance with the help of GServ.http() method and then at last we start the instance(i.e. the http server) with the help of start() method ( within start() method we pass in the port number here 9000, where the http server will be listening..... ), which eventually brings all the resources along with their resource actions, filter and other components in action.
gserv.http{
}.start(9000)
The delegate to the closure passed in to the http() is the ServerInstanceDelegate.
So whatever method call we define in the closure gets invoked from the Delegate.
Now that we know who inegrates all the components and makes them work together, The next question that arises is how does all these things takes place from registering resources, plugins, filters etc, to serving the requests when they arrive at a particular endpoint????
Lets describe the registration part first:
When we declare the following within the closure:
.http{
before "bookBeforeFilter2", "/data/book", "GET", [:], 4, {requestContext, data -> log.info "*********** ${requestContext.class} \n The data is $data"}
before "bookBeforeFilter1", "/data/book", "GET", [:], 4, {requestContext, data ->
log.info " ********** I am Done..... *********** "
requestContext
}
log.info "***** ${bookResource.basePath}"
log.info "***** ${bookResource.linkBuilder}"
addFilter beforeFilter
resource bookResource
}
The elements gets registered by the ServerInstanceDelegate within a Map declared in DelegateFunctions.
gServ Server Config
The following is a part of Server Config (i.e.GServConfig.java), we will get a more clear picture when we will explore the request flow from GServ :-).
Each key of the Map is the type of elements and has an associated List as the value for the Key, so that elements gets registered within that List, what I mean by this is for filters there is a key within the map named "filterList" and this key has a List associated with it, so all the filters gets registered within that list.
Likewise for resources there is "actionList" which contains all the actions corresponding to that resource.
In our case there are two actions for the BookResource, one is GET for the action path "/data/bookNoEnc" and other is POST for action path "/data/book".
One more thing, one significant task that http() method does apart from registering the above mentioned artifacts, is creating the GServConfig instance which contains all the configuration related data which we will be using while handling the incoming requests.
So in very brief this is how the Registration of the constituent elements does happen.
Now the question arises how the control flows, when the request arrives.
That I have tried to describe with a flow diagram Here. Please share your views and feedback and Till next time keep coding and keep contributing.
