Ask Questions and Find Answers

Development is already done in ga1. I have used ga3 for testing purpose.

That's the reason why any development should use the quite stable APIs, and not modify implementation directly: You'll have an easy way updating to the next release. This includes security issues, but also bugs like the one that you seem to have discovered. Short: If you limit yourself to exactly one GA version, you'll exclude yourself from future updates - and that includes security issues. You'd have to patch your version yourself.
Don't do that, move your code forward to GA3 (and then, after release, prepare to move to 7.2.x, for the same reasons. If you find that you're changing a lot of Liferay's implementation (through ext or direct patches of modules): Try to find a way to do so in a less intrusive way.

ok, Thanks to both of you.so, I need to use the upgradation tool as suggested in Liferay 7.1 docs. Then need to deploy all portlets and it will be fine right??

"...it will be fine": It depends on the customizations that you've done. If you've done them with maintenance minimization in mind: Most likely yes. If you've changed the implementation, bypassing the API: Prepare for some work.

Yeah, I figured it was a long shot and as I said, I don't think that actually fixed my issue but rather it was more of a coincidence that I did that and everything started working. For your question about dependencies, well, it all depends I suppose. Let's say for example you are using the journal-api and between the GA release there are API updates that are made that affect your code. If you can't use the older version then you would need to go through and update all of your versions everywhere you referenced it versus only having to make that change in one place. Really, it's a best practice that can make your life a lot easier. I recently upgraded a project that have about 80 modules and believe me, going through 80 build.gradle files to check them all sucked. Back to your problem though, are you sure your portal-ext is being picked up? Some things to try next.
1. When the portal is up and running, use the Server Administrator section in the control panel to check the value of the cluster.link.enabled property to make sure it is showing as true.2. Check the value of liferay.home (again in the control panel) and make sure it is referencing the right location, if it is not, then it might not be reading your portal-ext overrides3. Set a breakpoint where the cluster check is performed (during starting) and use your debugger to make sure that the result of the read operation returns the same result you have set in your portal-ext.. and maybe let us know what you find.

The caching that happens as part of a cluster config doesn't apply to the js, CSS, etc. It is applicable to the features that use ehcache such as the entity cache. Simplest test is this -1. Go to node 1 in your browser2. In a separate browser go to the same page, on node 23. On node 1 add a portlet to the page4. On node 2, refresh the page. If your cluster is working, then you should see the portlet on node 2 meaning the entity (layout) update on node 1 sent a message to node 2 and the cached record for that layout was purged. So when you refreshed node 2, the 'latest' version was cached after being pulled from the database.But if you don't see messages in your log during startup, the GMS output and references on the master node stating Accepted view when the second node is started, then it's probably node enabled.