Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Smartgwt 12.1 upgrade

    I upgraded from 12.0 to 12.1 and when i go to run i get the following error:

    === 2020-05-18 21:43:27,794 [7-18] ERROR Compression - Caught exception in doFilter() - for URI: /packager-1.0.0.0-SNAPSHOT/
    java.lang.IllegalStateException: Committed
    at org.eclipse.jetty.server.HttpChannel.resetBuffer(HttpChannel.java:928)
    at org.eclipse.jetty.server.HttpOutput.resetBuffer(HttpOutput.java:1080)
    at org.eclipse.jetty.server.Response.resetBuffer(Response.java:1100)
    at org.eclipse.jetty.server.Response.resetForForward(Response.java:1093)
    at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:146)
    at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:78)
    at org.eclipse.jetty.server.ResourceService.sendWelcome(ResourceService.java:432)
    at org.eclipse.jetty.server.ResourceService.doGet(ResourceService.java:251)
    at org.eclipse.jetty.servlet.DefaultServlet.doGet(DefaultServlet.java:457)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
    at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:876)
    at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1623)
    at org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:214)
    at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
    at com.isomorphic.servlet.CompressionFilter._doFilter(CompressionFilter.java:250)
    at com.isomorphic.servlet.BaseFilter.doFilter(BaseFilter.java:91)
    at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
    at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
    at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
    at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
    at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
    at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711)
    at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
    at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347)
    at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
    at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
    at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678)
    at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
    at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249)
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
    at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)
    at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:152)
    at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
    at org.eclipse.jetty.server.Server.handle(Server.java:505)
    at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370)
    at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267)
    at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
    at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
    at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
    at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
    at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:781)
    at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:917)
    at java.base/java.lang.Thread.run(Thread.java:830)

    Not sure where to start on how to fix the issue.

    #2
    We're barely in this stack, and it doesn't make a lot of sense: it seems like built-in Jetty code has tried to write out a response when the SmartGWT server has already started writing a response.

    In the process of upgrading to 12.1, you may have changed other things, such as the Jetty version, or introduced new things into web.xml? It doesn't make sense that this would be a new error resulting *only* from an upgrade of our software.

    Perhaps you added some new things from the new web.xml in 12.1, including perhaps our CompressionFilter, which you have now placed in front of some of your own code which expects to control the entire response? "/packager-1.0.0.0-SNAPSHOT" appears to be the URL, and that's not a default URL from our software.

    Comment


      #3
      Here is my web.xml. I dont think i have changed anything here. Most of the code has been static since last year.

      <?xml version="1.0" encoding="UTF-8"?>
      <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
      http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
      version="2.5"
      xmlns="http://java.sun.com/xml/ns/javaee">

      <!-- Servlets -->


      <!-- The DataSourceLoader servlet returns Javascript representations of the dataSources whose
      ID's are passed to it - it is an alternative to using the <loadDS> JSP tag -->
      <servlet>
      <servlet-name>DataSourceLoader</servlet-name>
      <servlet-class>com.isomorphic.servlet.DataSourceLoader</servlet-class>
      </servlet>

      <!-- DataSourceLoader requests -->
      <servlet-mapping>
      <servlet-name>DataSourceLoader</servlet-name>
      <url-pattern>/MdmsDataPackager/sc/DataSourceLoader</url-pattern>
      </servlet-mapping>

      <!-- Init: initializes SmartGWT framework. Note that we invoke the Init logic from
      both a Listener and a load-on-startup Servlet in this file - see the client-side
      documentation topic "com.smartgwt.client.docs.ServerInit" for a discussion of this. -->
      <listener>
      <listener-class>com.isomorphic.base.InitListener</listener-class>
      </listener>

      <servlet>
      <servlet-name>Init</servlet-name>
      <servlet-class>com.isomorphic.base.Init</servlet-class>
      <load-on-startup>1</load-on-startup>
      </servlet>

      <servlet>
      <servlet-name>HttpProxy</servlet-name>
      <servlet-class>com.isomorphic.servlet.HttpProxyServlet</servlet-class>
      </servlet>

      <!-- Dynamic Compression -->
      <filter>
      <filter-name>CompressionFilter</filter-name>
      <filter-class>com.isomorphic.servlet.CompressionFilter</filter-class>
      </filter>
      <!-- CompressionFilter for dynamic compression -->
      <filter-mapping>
      <filter-name>CompressionFilter</filter-name>
      <url-pattern>/*</url-pattern>
      </filter-mapping>

      <!-- The screenLoader servlet loads screen definitions in javascript notation -->
      <servlet>
      <servlet-name>screenLoader</servlet-name>
      <servlet-class>com.isomorphic.servlet.ScreenLoaderServlet</servlet-class>
      </servlet>
      <!-- The screenLoader servlet loads screen definitions in javascript notation -->
      <servlet-mapping>
      <servlet-name>screenLoader</servlet-name>
      <url-pattern>/MdmsDataPackager/sc/screenLoader</url-pattern>
      </servlet-mapping>


      <!-- The IDACall servlet handles all Built-in DataSource operations -->
      <servlet>
      <servlet-name>IDACall</servlet-name>
      <servlet-class>com.isomorphic.servlet.IDACall</servlet-class>
      </servlet>

      <!-- RPCManager uses this URL by default for Built-in DataSource operations -->
      <servlet-mapping>
      <servlet-name>IDACall</servlet-name>
      <url-pattern>/MdmsDataPackager/sc/IDACall/*</url-pattern>
      </servlet-mapping>


      <!-- The FileDownload servlet downloads static files, like a webserver -->
      <servlet>
      <servlet-name>FileDownload</servlet-name>
      <servlet-class>com.isomorphic.servlet.FileDownload</servlet-class>
      </servlet>

      <!-- Use FileDownload servlet to download all static content that's part of the skin, such as
      image files, so we can set Expires headers and other cache control directives. In a
      production deployment, you'd want to use a webserver such as Apache to do this.
      -->
      <servlet-mapping>
      <servlet-name>FileDownload</servlet-name>
      <url-pattern>/MdmsDataPackager/sc/skins/*</url-pattern>
      </servlet-mapping>

      <!-- serve ISC modules compressed, with expires headers -->
      <servlet-mapping>
      <servlet-name>FileDownload</servlet-name>
      <url-pattern>/MdmsDataPackager/sc/system/modules/*</url-pattern>
      </servlet-mapping>

      <!-- serve ISC development modules compressed, with expires headers -->
      <servlet-mapping>
      <servlet-name>FileDownload</servlet-name>
      <url-pattern>/MdmsDataPackager/sc/system/development/*</url-pattern>
      </servlet-mapping>

      <!-- serve skin assets with expires headers -->
      <servlet-mapping>
      <servlet-name>FileDownload</servlet-name>
      <url-pattern>/MdmsDataPackager/sc/system/reference/skin/*</url-pattern>
      </servlet-mapping>

      <!-- serve the contents of the helpers/ directory with expires headers -->
      <servlet-mapping>
      <servlet-name>FileDownload</servlet-name>
      <url-pattern>/MdmsDataPackager/sc/system/helpers/*</url-pattern>
      </servlet-mapping>



      <jsp-config>
      <!-- Isomorphic JSP tags -->
      <taglib>
      <taglib-uri>isomorphic</taglib-uri>
      <taglib-location>/WEB-INF/iscTaglib.xml</taglib-location>
      </taglib>
      </jsp-config>

      <mime-mapping>
      <extension>manifest</extension>
      <mime-type>text/cache-manifest</mime-type>
      </mime-mapping>

      <!-- Init: initializes MDMS Packager -->
      <servlet>
      <servlet-name>InitMDMSPackager</servlet-name>
      <servlet-class>com.harris.mdms.server.MdmsDataPackager</servlet-class>
      <load-on-startup>2</load-on-startup>
      </servlet>

      <!-- Default page to serve -->
      <welcome-file-list>
      <welcome-file>MdmsDataPackager.html</welcome-file>
      </welcome-file-list>

      </web-app>

      Comment


        #4
        I have now upgraded Jetty to a newer version to see if that would fix the problem. Version from -> to: 9.4.19.v20190610 -> 9.4.28.v20200408
        Now when my app starts no error other then i get a HTTP ERROR 503 Service Unavailable. So now i have no idea what to fix. My logs look like everything is working.

        Comment


          #5
          1. is this Jetty combined with Apache, Jetty standalone, Jetty launched by Eclipse or what? 503 typically means your app failed to deploy or is misconfigured, you can Google possible causes and look in Jetty logs

          2. did you go through the full setup or just copy in .jars (the latter would be wrong)?

          3. you ignored our question/comment about the "packager" URL and what's there (see post #2). We explained how that stack trace could arise, you should look into that.

          Comment


            #6
            It is a Jetty stand alone. I did not go through the full setup as i was given a sample project from another group and i modified it for my project. It has been working for a couple of years now so i was confident things were ok. I then upgraded to 12.1 which i like a lot as there is a lot of fixes that are super helpful to what i assume are just bugs. Anyways, I had to include joda-time version 2.10.6 as i was getting a class not found exception. Once i started getting that above illegal state exception , i upgraded jetty.

            My project is a maven project and runs in eclipse. This issue is when i deploy to a runtime environment of a stand alone jetty. I am not seeing any errors in the logs. I am seeing normal logs for a bean i am starting for some configuration. But when i try to start the page i get the 503. I did read up that it means it might be a configuration issue but where can i start to debug this. I suspect it might be something else i need to upgrade.

            Other things had to add for 12.1 upgrade:
            <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-lang3</artifactId>
            <version>3.10</version>
            </dependency>

            <dependency>
            <groupId>commons-io</groupId>
            <artifactId>commons-io</artifactId>
            <version>2.6</version>
            </dependency>

            <dependency>
            <groupId>commons-fileupload</groupId>
            <artifactId>commons-fileupload</artifactId>
            <version>1.4</version>
            </dependency>

            Web.xml had not changed and it is in post #3.

            Comment


              #7
              Here is my html page i think you are asking for
              Attached Files

              Comment


                #8
                OK at this point there is zero indication this is an issue with our product - seems to be some general Jetty issues - and you may not be aware, your support lapsed a while ago. We'll try to toss you some more help, but we will be pulled away by support issues.

                First thing, look in the *Jetty* log. It's not clear where you've been looking, but the Jetty log is where Jetty would be telling you why it's serving a 503. Our software does not produce that error.

                Second, your original stack trace was for "/packager-1.0.0.0-SNAPSHOT/". We keep asking what that is - it's again seemingly not part of our software - so what is it? Is that your application start page?

                Finally, if you can get past the 503, which suggests your app isn't really even deployed, you can try turning off our CompressionFilter in web.xml. You results suggest that you have set Jetty up in some way that it will crash if *any* filter servlets are installed, and that's the real problem to fix. But the CompressionFilter isn't required for operation, it's just an optimization, you can run without it.

                Comment


                  #9
                  Yes - sorry /packager-1.0.0.0-SNAPSHOT is my application start page. I will try to revert back to a slightly older version of Jetty. If i get that error, you are saying that i can remove the filter options in my web.xml. I do see two of them. Should i remove both? I am not tracking clearly what they are both doing or if they are one in the same. Also my app is download and uploading files of some size so will that cause an issue if those filters are removed?

                  thanks for your help.

                  Comment


                    #10
                    OK so your instance of Jetty is so broken it cannot server a plain .html file.

                    You still haven't shared any Jetty logs so that stops all analysis of actual causes.. upgrading or downgrading Jetty is kind of a random thing to do, and we would suggest that you look at the logs instead.

                    The CompressionFilter is the only filter in your web.xml.

                    There isn't any reason to suspect it's broken, but it's the only thing in the prior stack that is even related to our software. By removing it, you can then focus on how Jetty is broken rather than wondering if our software is involved.

                    Comment

                    Working...
                    X