Jianfeng Tian

Tuesday, April 30, 2013

-Xms Sets the initial heap memory size for the JVM-Xmx Sets the maximum heap memory the JVM allows grow up to.-XX:+UserParalleGC This instructs the JVM to make better user of multiple processors or cores

In an agile team, the backend dev can be the blocker in different development stages and the mock application can remove the blocker and let different development process (i.e front end, functional test, performance test) go in parallel with backend development..

Blocker 1 - for front end dev

If an agile team is composed of backend and frontend dev, and the front end dev consumes the apis developed by the backend dev. And then here is the blocker and waiting game for the frontend dev, as the backend api is in developing and can be buggy when released.

In this scenario, a mock application can help the frontend dev to continue with their development by calling the mock application instead of the real api. And when the backend dev finishes the api, then the frontend can switch the calling to it.

Blocker 2 - for functional testers

In an agile team, the functional testers can develop their automated script based on the API specification. But their script can only be verified when the backend dev finish their API development. And the testers might rework on their script by then.

The functional testers can verify their automated script by running it against the mock application, make the switch to the real API when the backend dev finish it.

Blocker 3 - for performance testers

In an agile team the performance tester normally get involved at the later stage - when the backend dev finish their API and the functional testers have tested it.

In this scenario, a mock application can let the performance testers start at an early stage. They don't have to wait for the backend dev to finish their API. Instead they can simply make their performance test calls to the mock application.

In unit and integration test, the afterPropertiesSet method has to be called otherwise the TOKEN won't be set. But noticeably, in unit test, the instances printed out by 'println this' are different, although grails service by default is a singleton implementation; but in integration test, the instance from 'println this' is the same.

Saturday, October 22, 2011

Jeff Brown explained Grails singleton service in Nabble. Below is his description.

"If your service has an instance variable (that is state) and you don't want that state to be shared by multiple concurrent users of the service, then you don't want that service to be a singleton. If a service is a singleton then every user of that service is sharing the same copy of the service. If a service is request scoped then a new instance is created for every http request. If a service is sessions scoped then the service will be kept around and reused for the entire user session (each user session has their own copy). "