nifi-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Senia (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (NIFI-1265) Precompiling message-page.jsp causes runtime error in CentOS 6.7 and Fedora 23
Date Thu, 05 May 2016 19:00:15 GMT

     [ https://issues.apache.org/jira/browse/NIFI-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Greg Senia updated NIFI-1265:
-----------------------------
    Attachment: jetty.447816.patch

[~mcgilman] I ran into this issue with Nifi 0.6.1 and master. What I did was I downloaded
the last stable version of jetty 9.2 and installed locally applied the patch above that I
took from the original project and Nifi was able to work..

	wget https://github.com/eclipse/jetty.project/archive/jetty-9.2.16.v20160414.zip -O jetty-9.2.16.v20160414.zip
Unzip Jetty Code Base:
	unzip jetty-9.2.16.v20160414.zip
Change Directory to Jetty Project FolderL
	cd jetty.project-jetty-9.2.16.v20160414/
	patch -p1 < ../jetty.447816.patch 
	mvn install -DskipTests

Compile/Build Nifi:
Enter the Nifi Release Directory:
	cd nifi-rel-nifi-0.6.1/
Adjust Jetty Version to local version that was installed previously into Maven:
	sed -i ’s;9.2.11.v20150529;9.2.16.v20160414;g’ -i pom.xml
Build Nifi and Package it. SkipTests to save time. No value on a release…
	mvn -T 2.0C clean package -DskipTests

> Precompiling message-page.jsp causes runtime error in CentOS 6.7 and Fedora 23
> ------------------------------------------------------------------------------
>
>                 Key: NIFI-1265
>                 URL: https://issues.apache.org/jira/browse/NIFI-1265
>             Project: Apache NiFi
>          Issue Type: Bug
>          Components: Core UI
>            Reporter: Matt Gilman
>            Priority: Minor
>             Fix For: 0.7.0
>
>         Attachments: jetty.447816.patch
>
>
> During start up it appears that when message-page.jsp is precompiled and run in CentOS
6.7 or Fedora 23 the following method in ServletHolder (Jetty) fails with:
> {noformat}
> 2015-12-07 10:01:26,557 WARN [main] org.apache.nifi.web.server.JettyServer
> Failed to start web server... shutting down.
> java.lang.IllegalArgumentException: Comparison method violates its general
> contract!
> at java.util.ComparableTimSort.mergeHi(ComparableTimSort.java:866)
> ~[na:1.8.0_65]
> at java.util.ComparableTimSort.mergeAt(ComparableTimSort.java:483)
> ~[na:1.8.0_65]
> at
> java.util.ComparableTimSort.mergeForceCollapse(ComparableTimSort.java:422)
> ~[na:1.8.0_65]
> at java.util.ComparableTimSort.sort(ComparableTimSort.java:222)
> ~[na:1.8.0_65]
> at java.util.Arrays.sort(Arrays.java:1246) ~[na:1.8.0_65]
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:865)
> ~[jetty-servlet-9.2.11.v20150529.jar:9.2.11.v20150529]
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
> ~[jetty-servlet-9.2.11.v20150529.jar:9.2.11.v20150529]
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
> ~[jetty-webapp-9.2.11.v20150529.jar:9.2.11.v20150529]
> {noformat}
> {code}
> @Override
>     public int compareTo(ServletHolder sh)
>     {
>         if (sh==this)
>             return 0;
>         if (sh._initOrder<_initOrder)
>             return 1;
>         if (sh._initOrder>_initOrder)
>             return -1;
>         int c=(_className!=null && sh._className!=null)?_className.compareTo(sh._className):0;
>         if (c==0)
>             c=_name.compareTo(sh._name);
>             return c;
>     }
> {code}
> After a quick glance it may be that this method is not transitive when falling back to
comparing by className and name. From the Java API
> {noformat}
> The implementor must also ensure that the relation is transitive: ((compare(x, y)>0)
&& (compare(y, z)>0)) implies compare(x, z)>0.
> {noformat}
> This could fail with the following scenario:
> {noformat}
> x._initOrder = -1
> x._className = null
> x._name = Login
> y._initOrder = -1
> y._className = org.apache.nifi.web.jsp.WEB_002dINF.pages.message_002dpage_jsp
> y._name = org.apache.nifi.web.jsp.WEB_002dINF.pages.message_002dpage_jsp
> z._initOrder = -1
> z._className = org.apache.nifi.web.servlet.DownloadSvg
> z._name = DownloadSvg
> {noformat}
> Unfortunately, I am unable to replicate the exception. However, my observation from debugging
show that when JSPs are precompiled the _className and _name are the same (like y above).
When a Servlet is referenced in the web.xml it's name is overridden (like z above). And when
a JSP is referenced in the web.xml the _className is null and the _name is set to the name
from the web.xml (like x above).
> In the scenario outlined: X < Y and Y < Z but Z < X. When running locally I
did not see the exception mentioned above but the resulting sort order was not correct as
it ultimately depended on which elements were compared to each other.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message