Bug 1121973 - custom jsp file can't take effect for jbosseap-6 app
Summary: custom jsp file can't take effect for jbosseap-6 app
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: OpenShift Online
Classification: Red Hat
Component: Image
Version: 2.x
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: Ben Parees
QA Contact: libra bugs
URL:
Whiteboard:
Depends On:
Blocks: 1188607
TreeView+ depends on / blocked
 
Reported: 2014-07-22 09:10 UTC by Yan Du
Modified: 2015-05-15 00:44 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-22 17:59:10 UTC


Attachments (Terms of Use)

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. ***


Note You need to log in before you can comment on or make changes to this bug.