502 Bad Gateway error throw in cloundfoundry tunneling Mongo Database - mongodb

I used the grails cloudfoundry plugin and tunnel to remote Mongo DB service. The connection is fine since I can do search for the first time, but after couple seconds, the terminal starts print out 502 Bad Gateway error and I am not able to execute any mongo db commands.
| Run cf-tunnel-disconnect to close the current tunnel
|
Error Exception in thread "ThreadPoolTaskExecutor-3"
| Error org.cloudfoundry.caldecott.TunnelException: Error while reading from tunnel
| Error at org.cloudfoundry.caldecott.client.TunnelHandler$Reader.run(TunnelHandler.java:172)
| Error at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
| Error at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
| Error at java.lang.Thread.run(Thread.java:680)
| Error Caused by: org.springframework.web.client.HttpServerErrorException: **502 Bad Gateway
| Error** at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:92)
| Error at org.springframework.web.client.RestTemplate.handleResponseError(RestTemplate.java:494)
| Error at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:451)
| Error at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:409)
| Error at org.cloudfoundry.caldecott.client.HttpTunnel.receiveDataBuffered(HttpTunnel.java:150)
| Error at org.cloudfoundry.caldecott.client.HttpTunnel.receiveBytes(HttpTunnel.java:140)
| Error at org.cloudfoundry.caldecott.client.HttpTunnel.read(HttpTunnel.java:83)
| Error at org.cloudfoundry.caldecott.client.TunnelHandler$Reader.run(TunnelHandler.java:148)
| Error ... 3 more

That looks like an error handling problem that was fixed in later releases of the cloudfoundry-caldecott-lib. The latest is 0.1.3 and is available from the Spring Source milestone repo (http://repo.springsource.org/libs-milestone/org/cloudfoundry/cloudfoundry-caldecott-lib/).
I'm not sure what version the Grails plugin uses, but if it's an older version, that would explain why you are seeing this.

Thanks #trisberg 's explanation and #scott 's finding, now I am able to use VMC to tunnel to my remote DB. Problem solved.

Related

Openshift Kubernetes Application fail to startup on Jetty server: java.net.URISyntaxException: Expected authority at index 7

I have an application running on a Jetty Server encapsulated in a Docker container. The same container deploys and works correctly on a local docker environment.
When deploying the container on OpenShift Kubernetes, Jetty errors with :
2021-11-13 18:07:01.667:WARN:oejw.WebAppContext:main: Failed startup of context o.e.j.q.QuickStartWebApp#39c0f4a{/,file:///opt/application/webapps/application/,UNAVAILABLE}{/application/}
java.lang.reflect.InvocationTargetException
Caused by:
java.lang.IllegalArgumentException: java.net.URISyntaxException: Expected authority at index 7: file://
at org.eclipse.jetty.quickstart.AttributeNormalizer.toCanonicalURI(AttributeNormalizer.java:93)
at org.eclipse.jetty.quickstart.AttributeNormalizer.add(AttributeNormalizer.java:208)
I understand the error is related to a URI which might be incorrectly formatted, but I'm struggling to understand where this one is configured, given that it works in a local docker environment.
Any suggestions on how to debug this are very welcome.
Looks like you have an incomplete file uri.
file://
That does not produce a valid URI on Java.
$ jshell
| Welcome to JShell -- Version 11.0.12
| For an introduction type: /help intro
jshell> new URI("file://")
| Exception java.net.URISyntaxException: Expected authority at index 7: file://
| at URI$Parser.fail (URI.java:2913)
| at URI$Parser.failExpecting (URI.java:2919)
| at URI$Parser.parseHierarchical (URI.java:3163)
| at URI$Parser.parse (URI.java:3114)
| at URI.<init> (URI.java:600)
| at (#1:1)
More of the stacktrace would help identify where that is coming from.

Fuse Karaf rest-dsl-simple missing

Trying the Fuse Karaf quickstarts "rest-dsl-simple" build and install in Fuse appears successful, however the tests do not. The both just say site cannot be reached.
Looking in Fuse.log I see...
2021-03-28 08:34:34,680 | INFO | FelixStartLevel | o.a.k.s.i.a.o.CommandExtension | 152 - org.apache.karaf.shell.core - 4.2.9.fuse-780023-redhat-00001 | Command registration delayed for bundle org.apache.karaf.http.core/4.2.9.fuse-780023-redhat-00001. Missing service: [org.apache.karaf.http.core.ServletService, org.apache.karaf.http.core.ProxyService]
Then later I see my bundle set to failure...
2021-03-28 08:34:43,066 | ERROR | Event Dispatcher: 1 | o.a.c.b.BlueprintCamelContext | 62 - org.apache.camel.camel-blueprint - 2.23.2.fuse-780036-redhat-00001 | Error occurred during starting CamelContext: fusequickstart-restdsl-simple-camel
org.apache.camel.FailedToCreateRouteException: Failed to create route route3: Route(route3)[[From[rest://get:/simplerest:/get?componentNam... because of No bean could be found in the registry for: restlet of type: org.apache.camel.spi.RestConsumerFactory
at
What feature(s) do I need to install to rectify this error?
I fixed it by going to the http://localhost:8181/hawtio/osgi/features and filtering on REST features and installing them. Yes I know shotgun approach but it will ensure whatever technology I choose down the road will likely be covered.
Now rest-dsl-simple fuse karaf quickstart is working and now I can move to my code, knowing the fuse-karaf engine is running normally.
:-)

Creating PostgreSQL DataSource via pax-jdbc config file on karaf 4

On my karaf 4.0.8 I've installed the feature pax-jdbc-postgresql. The DataFactory for PostgreSQL is installed:
org.osgi.service.jdbc.DataSourceFactory]
osgi.jdbc.driver.class org.postgresql.Driver
osgi.jdbc.driver.name PostgreSQL JDBC Driver
osgi.jdbc.driver.version PostgreSQL 9.4 JDBC4.1 (build 1203)
service.bundleid 204
service.scope singleton
Using Bundles com.eclipsesource.jaxrs.publisher (184)
I've create the file etc/org.ops4j.datasource-psql-sandbox.cfg:
osgi.jdbc.driver.class=org.postgresql.Driver
osgi.jdbc.driver.name=PostgreSQL
url=jdbc:postgresql://localhost:5432/sandbox
dataSourceName=psql-sandbox
user=sandbox
password=sandbox
After that, I see the confirmation in karaf.log that the file was processed:
2017-02-10 14:54:17,468 | INFO | 41-88b277ae0921) |
DataSourceRegistration | 154 - org.ops4j.pax.jdbc.config -
0.9.0 | Detected config for DataSource psql-sandbox. Tracking DSF with filter
(&(objectClass=org.osgi.service.jdbc.DataSourceFactory)(osgi.jdbc.driver.class=org.postgresql.Driver)(osgi.jdbc.driver.name=PostgreSQL))
However, I see no new DataSource in services list in console. What went wrong? I see no exceptions in log ....
The log message tell you that the config was processed and it is now searching for a suitable DataSourceFactory OSGi service.
The problem in your case is that it does not find such a service. So to debug this you should list all DataSourceFactory services and check their properties.
service:list DataSourceFactory
In my case it shows this:
[org.osgi.service.jdbc.DataSourceFactory]
-----------------------------------------
osgi.jdbc.driver.class = org.postgresql.Driver
osgi.jdbc.driver.name = PostgreSQL JDBC Driver
...
As you see it does not match the filter you see in the log. Generally you should only provide either osgi.jdbc.driver.class or osgi.jdbc.driver.name not both. If you remove the osgi.jdbc.driver.name line the config will work.
There is no error message as the system can not know if the error is transient or not. Basically as soon as you install a matching OSGi service the DataSource will be created.

Using NGSI Adapter to post updates to Orion Context Broker

I’m trying to use the Monitoring GE / Sextant tool called NGSI Adapter. I am trying to run the command line suggestion from https://github.com/telefonicaid/fiware-monitoring/blob/develop/README.rst#api-overview
I always get this response:
time=2016-03-16T11:06:18.794Z | lvl=INFO | trans=ciluqsqi1000077m2u9zwb8x5 | op=POST | msg=Request on resource /check_load with params id=host_1&type=host
time=2016-03-16T11:06:18.800Z | lvl=INFO | trans=ciluqsqi1000077m2u9zwb8x5 | op=POST | msg=Response status 200 OK
time=2016-03-16T11:05:07.004Z | lvl=INFO | trans=ciluqr73e0000umm2nir549ts | op=UpdateContext | msg=Request to ContextBroker at http://orion:1026...
time=2016-03-16T11:05:07.013Z | lvl=INFO | trans=ciluqr73e0000umm2nir549ts | op=UpdateContext | msg=Response status 415 Unsupported Media Type
From looking at the release notes to Orion 3.4.1, "Unsupported Media Type" indicates that the Content-Type in the request header is unacceptable. From browsing the code in lib/parsers/common/base.js it seems like NGSI Adapter only currently supports xml. I think that Orion now only supports JSON.
Am I correct that this incompatibility between NGSI Adapter and Orion exists?
When is a fix expected?
You're right.
Taking a look at the release notes, you’ll find that Orion 0.28.0 is the last version which includes XML support (deprecated since 0.23.0).
For that reason, a new NGSI Adapter v1.4.0 (included as part of FIWARE Monitoring 5.2.3) has been released. Please follow these instructions to install it and check documentation at ReadTheDocs.
Thank you for using FIWARE Monitoring.

GenericSignatureFormatError in Play! Scala blog example

I'm working my way through the Scala blog engine tutorial (yabe) for Play! Framework, and I encountered a template execution error that refers to GenericSignatureFormatError : null when accessing comments. Specifically, the error page says:
Template execution error
Execution error occured in template /app/views/tags/display.html.
Exception raised was GenericSignatureFormatError : null.
In /app/views/tags/display.html (around line 14)
(14) | ${_arg?.comments.size() ?: 'no'}
This exception has been logged with id 666i6ifgg
The stack trace from the console is below. I can reproduce the problem within samples-and-tests/ from the github master (43b195), as follows:
% git clone https://github.com/playframework/play-scala.git
% cd play-scala/samples-and-tests/yabe
% play dependencies
~ play! 1.2, http://www.playframework.org
~ Resolving dependencies using /home/league/tmp/play-scala/samples-and-tests/yabe/conf/dependencies.yml,
~ play->scala 0.9 (from playLocalModules)
~ Installing resolved dependencies,
~ modules/scala-0.9 -> /usr/local/stow/play-1.2/share/play-1.2/modules/scala-0.9
~ lib/joda-time-1.6.jar
~ Done!
% play run
~ play! 1.2, http://www.playframework.org
~ Warning: conflict on command scala:console
~ Ctrl+C to stop
Listening for transport dt_socket at address: 8000
10:32:01,076 INFO ~ Starting /home/league/tmp/play-scala/samples-and-tests/yabe
10:32:01,079 WARN ~ Declaring modules in application.conf is deprecated. Use dependencies.yml instead (module.scala)
10:32:01,080 INFO ~ Module scala is available (/home/league/tmp/play-scala/samples-and-tests/yabe/../..)
10:32:01,080 INFO ~ Module scala is available (/usr/local/stow/play-1.2/share/play-1.2/modules/scala-0.9)
10:32:02,515 WARN ~ You're running Play! in DEV mode
10:32:02,591 INFO ~ Listening for HTTP on port 9000 (Waiting a first request to start) ...
Then, loading http://localhost:9000/ produces the error stated above, with this console output:
#666i6ifgg
Internal Server Error (500) for request GET /
Template execution error (In /app/views/tags/display.html around line 14)
Execution error occured in template /app/views/tags/display.html. Exception raised was GenericSignatureFormatError : null.
play.exceptions.TemplateExecutionException
at play.templates.BaseTemplate.throwException(BaseTemplate.java:84)
at play.templates.GroovyTemplate.internalRender(GroovyTemplate.java:236)
at play.templates.GroovyTemplate$ExecutableTemplate.invokeTag(GroovyTemplate.java:346)
at /app/views/Application/index.html.(line:6)
at play.templates.GroovyTemplate.internalRender(GroovyTemplate.java:213)
at play.templates.Template.render(Template.java:26)
at play.mvc.results.RenderTemplate.<init>(RenderTemplate.java:24)
at play.mvc.Controller.renderTemplate(Controller.java:657)
at play.mvc.ControllerDelegate.renderTemplateForScala(ControllerDelegate.java:46)
at play.mvc.results.Template.<init>(Template.scala:12)
at play.mvc.ScalaController.Template(ScalaController.scala:77)
at controllers.Application$.index(app/controllers.scala:27)
at play.mvc.ActionInvoker.invokeWithContinuation(ActionInvoker.java:540)
at play.mvc.ActionInvoker.invoke(ActionInvoker.java:498)
at play.mvc.ActionInvoker.invokeControllerMethod(ActionInvoker.java:492)
at play.mvc.ActionInvoker.invokeControllerMethod(ActionInvoker.java:469)
at play.mvc.ActionInvoker.invoke(ActionInvoker.java:157)
at Invocation.HTTP Request(Play!)
Caused by: java.lang.reflect.GenericSignatureFormatError
at java.beans.FeatureDescriptor.getParameterTypes(FeatureDescriptor.java:385)
at java.beans.MethodDescriptor.setMethod(MethodDescriptor.java:116)
at java.beans.MethodDescriptor.<init>(MethodDescriptor.java:74)
at java.beans.MethodDescriptor.<init>(MethodDescriptor.java:58)
at java.beans.Introspector.getTargetMethodInfo(Introspector.java:1196)
at java.beans.Introspector.getBeanInfo(Introspector.java:423)
at java.beans.Introspector.getBeanInfo(Introspector.java:189)
at java.beans.Introspector.getBeanInfo(Introspector.java:250)
at java.beans.Introspector.<init>(Introspector.java:404)
at java.beans.Introspector.getBeanInfo(Introspector.java:189)
at java.security.AccessController.doPrivileged(Native Method)
at /app/views/tags/display.html.(line:14)
at play.templates.GroovyTemplate.internalRender(GroovyTemplate.java:213)
... 16 more
I was able to work around this problem by switching to the Sun JDK. I didn't realize that my Ubuntu was set to use OpenJDK instead. The installation guide claims that either one should work. Perhaps that is untrue, or perhaps I got unlucky with a particular bug related to this version of OpenJDK.
For anyone else having this problem, update-java-alternatives -l shows the available JDKs; I see:
java-6-openjdk 1061 /usr/lib/jvm/java-6-openjdk
java-6-sun 63 /usr/lib/jvm/java-6-sun
These come from the Ubuntu packages
sun-java6-bin 6.24-1build0.10.10.1
openjdk-6-jre-headless 6b20-1.9.7-0ubuntu1
Use this to select:
update-java-alternatives -s java-6-sun
Try changing this:
${_arg?.comments.size() ?: 'no'}
to
${(_arg?.comments.size() > 0) ? '': 'no'}
This should work.