Life beyond compat

[Vinay Chitlangia]

So I started moving the code to life after beyond compat.

From jetty9-compat to jetty9.

The transition was alright except...

the logs that are written as a part of the request come in

stderr/stdout instead of in request log. What is the trick to make them part of the request log.

Nothing seems to be getting traced now. What is the recommendation to hook up tracing?

[George (Cloud Platform Support)]

How did you conduct the transition, step-by-step?

One of the necessary configuration steps might have a direct influence on the issues you mention, namely: “Customizing the Java 8 / Jetty 9.3 runtime” from the “The Java 8 / Jetty 9.3 Runtime” document.

More details, such that you deem relevant, may prove of help as well.

[Vinay Chitlangia]

Thanks for the response.

Yes, I have followed the steps in the document you have mentioned. (You mentioned one of the step has a direct influence, which step is that)

I modified the docker file to add requestlog. However that did not seem to have any impact. Attached is the screenshot of the log.

The message about memcache host and port is written in the readhandler (and should have been part of the request log).

The app.yaml is in src/main/appengine directory and fairly vanilla.

runtime: custom

env: flex

handlers:

- url: /.*

  script: this field is required, but ignored

  secure: always

env_variables:

  USE_GAE_MEMCACHE: 1

--
You received this message because you are subscribed to a topic in the Google Groups "Google App Engine" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-appengine/FfR1B38yUEo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-appengine+unsubscribe@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/64b6afe7-6f43-4123-9bb5-5bc13e1511b6%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Vinay Chitlangia]

And here is the dockerfile: (In addition to the one mentioned in the transition doc, we also install openjdk8 in this, and ofcourse add requestlog in the startup command).

FROM gcr.io/google-appengine/jetty9

RUN apt-get -q update && \

    apt-get -y -q --no-install-recommends -t jessie-backports install openjdk-8-jdk && \

    apt-get clean && \

    rm /var/lib/apt/lists/*_*

ADD backend.war $JETTY_BASE/webapps/root.war

WORKDIR $JETTY_BASE

RUN java -jar $JETTY_HOME/start.jar --approve-all-licenses \

 --add-to-startd=jmx,stats,hawtio,requestlog \

 && chown -R jetty:jetty $JETTY_BASE

On Sat, Mar 4, 2017 at 10:25 AM, Vinay Chitlangia <chitl...@gmail.com> wrote:

Thanks for the response.

Yes, I have followed the steps in the document you have mentioned. (You mentioned one of the step has a direct influence, which step is that)

I modified the docker file to add requestlog. However that did not seem to have any impact. Attached is the screenshot of the log.

The message about memcache host and port is written in the readhandler (and should have been part of the request log).

The app.yaml is in src/main/appengine directory and fairly vanilla.

runtime: custom

env: flex

handlers:

- url: /.*

  script: this field is required, but ignored

  secure: always

env_variables:

  USE_GAE_MEMCACHE: 1

[George (Cloud Platform Support)]

The Memcache service is currently not available for the App Engine flexible environment, as mentioned in the "Upgrading to the Latest App Engine Flexible Environment Beta Release" document. If your code contains calls to memcache, errors are to be expected, as seen in your attached screen capture. If you need access to a memcache service immediately, you can use the third party memcache service from Redis Labs. 

Jetty's default behavior assumes presence of the slf4j facade in your system. If slf4j is present in your classpath, it will emit logging events to slf4j to handle, using the Slf4jLog handler. This does not seem to happen in your case, and the behavior observed corresponds more likely to a fallback to StdErrLog, emitting to System.err. More details on Jetty logging may be found in the "How to enable logging in jetty?" entry from Stackoverflow.