Bug 1121973

Summary:	custom jsp file can't take effect for jbosseap-6 app
Product:	OpenShift Online	Reporter:	Yan Du <yadu>
Component:	Image	Assignee:	Ben Parees <bparees>
Status:	CLOSED CANTFIX	QA Contact:	libra bugs <libra-bugs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	2.x	CC:	akostadi, jokerman, mmccomas
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-07-22 17:59:10 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1188607

Description Yan Du 2014-07-22 09:10:38 UTC

Description of problem:

Create a jbosseap-6 app, custom the jsp file in repo and git push. the custom jsp page could show correctly in web.

Then change the jsp file again in repo and git push, the change won't take effect when access the app in web.



Version-Release number of selected component (if applicable):
devenv_4992



How reproducible:
always



Steps to Reproduce:

1. create a jbosseap-6 app
2. create a new page under src/main/webapp/ dir with the following code:
<--------testpage.jsp-------->
 <html>
   <head><title>WebPage factory</title></head>
   <body>
     <% out.println("version 1"); %>
   </body>
 </html>
<---------------------------->
4. push the change
5. check the $app-url/testpage.jsp page to see if the change takes effect (print "version 1")
6. change the testpage.jsp again
  eg: change version 1 to version 2
<--------testpage.jsp-------->
 <html>
   <head><title>WebPage factory</title></head>
   <body>
     <% out.println("version version 2"); %>
   </body>
 </html>
<---------------------------->
7. git push 
8. access the app in web $app-url/testpage.jsp
9. restart the app and access the app again



Actual results:
always got version 1 in step8-9


Expected results:
show version 2 in step8


Additional info:
issue can't be reproduced for jbossas7 app

Comment 1 Ben Parees 2014-07-22 15:41:47 UTC

The issue appears to be in jboss jsp caching.  The compiled testpage.jsp file ends up cached here:

/var/lib/openshift/53cebc02186355494c00004e/jbosseap/standalone/tmp/work/jboss.web/default-host/_/org/apache/jsp

with the current time from the openshift node.

meanwhile, the actual jsp is stored here with the time from the openshift client machine:
/var/lib/openshift/53cebc02186355494c00004e/jbosseap/standalone/tmp/vfs/temp/tempd56ce3f88d7750b9/ROOT.war-937230a5bc488ab6/testpage.jsp

In this case, the openshift node has a significantly advanced clock.  As a result, jboss sees the timestamp of the jsp as being older than the latest cached compiled classes (again, stored in:
/var/lib/openshift/53cebc02186355494c00004e/jbosseap/standalone/tmp/work/jboss.web/default-host/_/org/apache/jsp)

and so it does not update the cached copy with the contents in /var/lib/openshift/53cebc02186355494c00004e/jbosseap/standalone/tmp/vfs/temp/tempd56ce3f88d7750b9/ROOT.war-937230a5bc488ab6/testpage.jsp

For some reason on jbossAS, the timestamp in /var/lib/openshift/53cebc02186355494c00004e/jbosseap/standalone/tmp/vfs reflects the time on the openshift node, so this problem does not occur.

The simple solution would be to wipe out the tmp directory as part of deploy, though this would have negative performance implications since cached classes that have not changed would be lost.

Otherwise I need to speak w/ the jboss team to understand this behavior.

Comment 3 Ben Parees 2015-03-06 16:40:21 UTC

*** Bug 1199301 has been marked as a duplicate of this bug. ***