I am trying to run my Spring boot application on AWS using boxfuse.
I have followed the following tutorial from Spring (section 54.4) and the Get Started from Boxfuse aswell.
When i run the following command
boxfuse run target\digigram-0.1.0.jar -env=prod
i get the following lines
Waiting for AWS to boot Instance i-74fe7fc8 and Payload to start at http://52.28.94.159:8080/ ...
WARNING: Healthcheck (http://52.28.94.159:8080/) returned 404 instead of 200. Retrying for the next 120 seconds ...
Terminating instance i-74fe7fc8 ...
And it ends with
Destroying Security Group sg-0ed6f667 ...
ERROR: Deployment of pantera160/digigram:0.0.0.1453900589995 failed in prod:Payload of Instance i-74fe7fc8 came up at http://52.28.94.159:8080/
with HTTP 404 (expected 200) => ensure your application responds with an HTTP 200 at http://52.28.94.159:8080/ or adjust the healthcheck configuration (healthcheck.path, healthcheck.timeout, ...) to fit your application
ERROR: Running pantera160/digigram:0.0.0.1453900589995 failed!
I don't understand where the problem lies. Do I have to change something in AWS or in my application or...
Any help would be greatly appreciated.
NOTE:
I am running on a free plan for AWS, might this be the problem?
Boxfuse ensures that a correct version of your app stays up and running and does not get replaced by a bad one. Only when a new version does pass Boxfuse's health check, does Boxfuse reassign it the application's Elastic IP. Once that is complete Boxfuse terminates the instance of the old version.
To verify that a new version of your app comes up correctly Boxfuse expects the new version's instance's healthcheck path to return HTTP 200.
The default healthcheck path for a regular Spring Boot application without the actuator is /. Your app currently answers 404 there instead of 200.
You have a number of options to fix this:
Add a controller to your app mapped to / that returns HTTP 200 when your app comes up correctly.
Change Boxfuse's healthcheck.path to a different path that does indeed answer HTTP 200 when your app comes up correctly.
Disable Boxfuse's health checks by setting healthcheck to false (not recommended as this effectively prevents Boxfuse from checking whether your application came up correctly)
Pick either one of these options and your app will come up correctly as you would expect.
Related
I run a proxy on localhost:2080 for debugging purposes. I can see trafic going through my proxy using either:
curl http://localhost:8888/stuff --proxy localhost:2080
curl http://some.server.com:8888/stuff --proxy localhost:2080
Using a Spring application, or a bare bones HttpURLConnectionExample Java application, I see requests go through the proxy when I call some.server.com, but never on localhost, even though I set http.nonProxyHosts to a random value (to avoid the default of localhost).
I made sure my JVM arguments were taken into accounts by adding the following code:
System.out.println("java.version="+props.getProperty("java.version"));
System.out.println("http.proxyHost="+props.getProperty("http.proxyHost"));
System.out.println("http.proxyPort="+props.getProperty("http.proxyPort"));
System.out.println("http.nonProxyHosts="+props.getProperty("http.nonProxyHosts"));
That produces the following output:
java.version=1.8.0_131
http.proxyHost=localhost
http.proxyPort=2080
http.nonProxyHosts=dummy.snafu.com
https.proxyHost=localhost
https.proxyPort=2080
https.nonProxyHost=dummy.snafu.com
Testing 1 - Send Http GET request
Sending 'GET' request to URL : http://localhost:8888/stuff
Response Code : 200
hello
Why are HTTP requests to localhost not going through my proxy when run with the following JVM arguments?
-Dhttp.proxyHost=localhost
-Dhttp.proxyPort=2080
-Dhttp.nonProxyHosts=dummy.snafu.com
This is a limitation of DefaultProxySelector, It always appends local Uris(localhost, 127.*, etc) to whatever you configure as nonProxyHosts, essentially bypassing proxy for all local Uris(localhost|127. *|[::1]|0.0.0.0|[::0]). Fortunately, there is a workaround by creating your own proxy selector and registering it as default.
We have implemented webservice call using JAX-WS RI 2.1.6 in JDK 6 now problem comes when we enable https webservice call stops reaching server and java reports following error,
javax.xml.ws.WebServiceException: java.io.IOException: Async IO
operation failed (3), reason: RC: 55 The specified network resource
or device is no longer available.
Now I have tested this within SoapUI and response from the service is received there.
Looked into various solution where it tells us to provide timeout settings but nothing seems work.
#WebEndpoint(name = "RulesSoap")
public RulesSoap getRulesSoap() {
((BindingProvider)super.getPort(new QName("urn:decision:Rules", "RulesSoap"), RulesSoap.class)).getRequestContext().put("com.sun.xml.internal.ws.connect.timeout", 1000);
((BindingProvider)super.getPort(new QName("urn:decision:Rules", "RulesSoap"), RulesSoap.class)).getRequestContext().put("com.sun.xml.internal.ws.request.timeout", 1000);
return super.getPort(new QName("urn:decision:Rules", "RulesSoap"), RulesSoap.class);
}
And just for information JAX-WS implementation is following few simple lines,
of course we submit all necessary data into respective stubs and all but I am not submitting here because our http calls are getting through,
Rules rules = new Rules(new URL(url), new QName("urn:decision:Rules", "Rules"));
RulesSoap rulesSoap = rules.getRulesSoap();
CorticonResponse response = rulesSoap.processRequest(request);
Note : Our application server WebSphere Application Server and Version 7.0.0.19
Thanks in Advance.
After lots of efforts we resolved this. I will provide steps if anything related to this happens how to find root cause,
Step 1 :
First of all we enabled soap tracing in WebSphere Application Server by following setting,
Admin Console > Servers > Server Types > WebSphere Application Servers >
{your server} > Troubleshooting > Change Log Detail Levels > Runtime
In run time please put this , *=info: com.ibm.ws.websvcs.*=all: org.apache.axis2.jaxws.*=all
This step will create trace.log file in your logs folder.
Now any web service request which goes out of your server will add logs to this file and necessary props like endpoint, request, response etc.
Step 2 :
Reading this trace.log file we found following endpoint,
PropertyValid 1 org.apache.axis2.jaxws.client.PropertyValidator validate validate property=(javax.xml.ws.service.endpoint.address) with value=(http://uxm.solutions.lnet.com:9445/axis/dswsdl/Rules/1/0)
HTTPConnectio 3 resetConnection : http://uxm.solutions.lnet.com:9445/axis/dswsdl/Rules/1/0 Persistent : true
Now if you notice here that our soap has endpoint address javax.xml.ws.service.endpoint.address where protocol is still using http which causes to fail ssl handshake.
Step 3 :
Solution for this is to override endpoint inside your soap stubs which can be implemented by adding following line,
RulesSoap rulesSoap = rules.getRulesSoap();
((BindingProvider)rulesSoap).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "https://uxm.solutions.lnet.com:9445/axis/dswsdl/Rules/1/0");
Conclusion :
So here is what i think even we pass https url while we are creating objects but still does not take this https url on runtime, to me this looks like stubs creation issue with JAX-WS.
Thanks.
What protocol /ciphers are you using? You have mentioned there is connection to webservice on WAS7 with JDK6 and Java 6 does not support TLS1.2 (and TLS1.1 only from certain fixpack).
See this:
How to use TLS 1.2 in Java 6
Yesterday if was opening http://my-ip:3000/solr then the home page is opening of Solr.
But today I restarted VM after that is showing me like that.
HTTP ERROR: 404
Problem accessing /solr. Reason:
Not Found
Powered by Jetty://
If I run this URL http://my-ip:3000 then it shows me
Error 404 - Not Found.
No context on this server matched or handled this request.
Contexts known to this server are:
Powered by Jetty:// Java Web Server
I checked Jetty and it is running fine.
Now I'm confused whats not running. I'm new to Solr. Please help me?
Solr page is now opening on this URL http://my-ip:3000/solr
And showing me 4.4
I killed java process then it starts working
You may need going to the Solr directory: cd solr-6.2.0/ and launching it: bin/solr start The Solr admin UI will run on the port 8983 by default: http://localhost:8983/solr/. However, the support for deploying Solr 5.0 and newer on Jetty is unsuported, so you might consider another solution, without Jetty.
I am creating web-service APIs using the Play framework with Java. I have created the service successfully.
WHAT I DID:
In one web service request, I have sent the base64 string. If I passed the base64 string in the request, I got the below exception.
[warn] p.nettyException - Handling TooLongFrameException
org.jboss.netty.handler.codec.frame.TooLongFrameException: An HTTP line is larger than 4096 bytes.
After searching in the internet, I got the below solution.
export SBT_OPTS="-Xms1024m -Xmx3084m -XX:MaxPermSize=1024m -Dhttp.netty.maxInitialLineLength=8192"
After setting the SBT_OPTS, I can pass the base64 string in the request and receive it on the server side successfully.
I used the following command for debugging purpose - "activator -jvm-debug 9999 run". So it is working fine.
WHAT IS ISSUE:
But now I tried to deploy this as service. So that I used the following commands - "activator start" (or) "activator start $SBT_OPTS" (or) "activator $SBT_OPTS start".
When I use this commands to start the service, I got the same above issue - "An HTTP line is larger than 4096 bytes."
Can anyone help me to fix this issue?
Please add the below line in your application.conf, then you don't need to set any config at runtime
parsers.text.maxLength=7024K
Its accept the request data upto 7MB, if you need more, you can set it.
https://www.playframework.com/documentation/2.3.x/JavaBodyParsers
I'm working with the Dropwizard sample project from the tutorial and faced the following strange issue:
With the following server config
server:
type: default
applicationConnectors:
- type: http
port: 8080
My resource returns the correct response.
When I change it to:
server:
type: simple
I see (from Jetty's logs) that it was correctly registered and loaded but doesn't work - if I try the same path I see 404 in browser and
GET /wizard-resource/rs 200
in the logs. I've tried to find the difference between simple and default in yaml configs but Google didn't shed much light on the topic.
So, here are two questions:
Why with simple connector do I get a 200 in logs but 404 in browser?
What is the use of simple connector and when it is better than default?
According to Dropwizard Javadocs:
Simple Server
A single-connector implementation of {#link ServerFactory}, suitable
for PaaS deployments (e.g., Heroku) where applications are limited to
a single, runtime-defined port. A startup script can override the
port via {#code -Ddw.server.connector.port=$PORT}.
Default Server
The default implementation of {#link ServerFactory}, which allows for
multiple sets of application and admin connectors, all running on
separate ports. Admin connectors use a separate thread pool to keep
the control and data planes separate(ish).
It's also mentioned (though not thoroughly) in the Configuration Reference documentation.
Not sure why it's logged as 200 while it's 404, it could be a bug; but the reason you're getting 404 could be because the default applicationContextPath config in simple server is /application. So if you try
GET /application/wizard-resource/rs
it should work.