Is it possible to make use of spring-retry within dropwizard? Or, for that sake, is there something like spring-retry in dropwizard?
Not sure of wha spring retry does, but for client retries, you can configure retries for HttpClient
httpClient:
timeout: 500ms
retries: 3
The number of times to retry failed requests. Requests are only retried if they throw an exception other than InterruptedIOException, UnknownHostException, ConnectException, or SSLException.
See Dropwizard documenation
From Spring Batch - Reference Documentation, 9. Retry:
The retry functionality was pulled out of Spring Batch as of 2.2.0. It is now part of a new library, Spring Retry.
Spring Retry can be used independently of other Spring projects.
e.g. In a Maven project you can simply add the following in your POM:
<dependency>
<groupId>org.springframework.retry</groupId>
<artifactId>spring-retry</artifactId>
<version>1.1.5.RELEASE</version>
</dependency>
Related
I trying to manage my streams on spring cloud data flow with skipper server.
I followed the instruction here:
https://docs.spring.io/spring-cloud-dataflow/docs/current/reference/htmlsingle/#getting-started-deploying-spring-cloud-dataflow
The app registration and stream definition/deployment goes quite well, but after I undeploy the deployed stream, I can't see any stream on the dashboard any more.
The dashboard shows an error instead:
Could not parse Skipper Platform Status JSON:null
I have to restart the scdf server and skipper server in order to see my stream definition again.
The version of the components are:
scdf local server: 1.6.0.RELEASE
skipper server: 1.0.8.RELEASE
metrics collector: kafka-10-1.0.0.RELEASE
Some operation details:
I registered my app using scdf shell in skipper mode.
I defined and depolyed my stream on the scdf dashboard. I undeployed the stream via the stop button on the dashboard, too.
How should I solve this problem?
We have recently observed this on our side, too, and it has been fixed! [see spring-cloud/spring-cloud-dataflow#2361]
We are preparing for a 1.6.1 GA release, but in the meantime, please feel free to pull the 1.6.1.BUILD-SNAPSHOT from Spring repo and give it a go.
If you see any other anomaly, it'd be great to have a bug report on the matter.
Spring boot admin is a great tool to make the health and metrics of my spring boot application (in my case a web-server) available. I've followed the reference guide and could finally get it to run, with one exception though: The server doesn't seem to recognize if the client crashes/goes down.
For testing I currently use separate applications, both running on the same host. In the final version I plan to have multiple clients (running on separate IP addresses) to register with a single server running on its separate IP).
Server (a separate spring boot project)
pom.xml
...
<dependency>
<groupId>de.codecentric</groupId>
<artifactId>spring-boot-admin-server</artifactId>
</dependency>
<dependency>
<groupId>de.codecentric</groupId>
<artifactId>spring-boot-admin-server-ui</artifactId>
</dependency>
...
application.properties:
server.port=8081
MyMain:
#Configuration
#EnableAutoConfiguration
#EnableAdminServer
public class MyMain {
public static void main(String[] args) {
SpringApplication.run(MyMain.class, args);
}
}
Client (my WebApp to be monitored):
pom.xml:
...
<!-- SPRING BOOT ADMIN (CLIENT) -->
<dependency>
<groupId>de.codecentric</groupId>
<artifactId>spring-boot-admin-starter-client</artifactId>
</dependency>
...
application.properties:
server.port=8080
spring.boot.admin.url=http://localhost:8081
spring.boot.admin.client.management-url=http://localhost:8081
spring.boot.admin.client.service-url=http://localhost:8080
spring.boot.admin.client.name=my-rest-app
With this setup I can connect to http://localhost:8080 to get my web-app or to http://localhost:8081 to see the admin/monitoring UI. The status shows UP and I can browse the mem/heap/traces/...
The issue now is, that if I kill the web-app the status remains UP.
From the description I would have assumed that the server property spring.boot.admin.monitor.period is checking every 10s the status of the clients app.
Or, do I require the notification feature for this?
Try running the application through the command line from your project directory -
mvn spring-boot:run
It's simple.
spring.boot.admin.auto-deregistration=true
Set this in your application.properties.
Keep in mind, this only works when your application is terminated gracefully or using SIGTERM (kill -15 PID).
In case you kill your application, the app won't deregister itself because the context was not closed properly.
See more here- https://codecentric.github.io/spring-boot-admin/1.4.3/#spring-boot-admin-client
Greeting,
I'm trying to make this example work in Grails 2.1 using atmosphere plugin. When running in development environment on Tomcat it does not work, probably because Tomcat does not support web-services.
So I'm deploying it on JBoss 7.1. It does not work as well. And the following exception could be found in the log file
AtmosphereFramework exception: java.lang.IllegalStateException: The servlet or filters
that are being used by this request do not support async operation
I found the article related to async servlets support in Grails. Seems that Servlet3AsyncWebXmlProcessor should add async support to web.xml. But somebody should invoke it.
I think that atmosphere plugin is responsible for allowing async communication.
Have I missed something? Could you please help to make it work on AS7?
Ideally, I would like to figure out the way of running atmosphere applications in development environment? Is it possible?
This works locally. Set up: Grails 2.0.3. Debain Linux. I've deployed other applications successfully to Cloud Foundry.
Apparently this thing can happen as a consequence of the Spring Security Plugin not being happy with the resources plugin. Removing the resources plugin doesn't cure this.
This is the problem:
Class: java.lang.IllegalStateException
Message: No thread-bound request found: Are you referring to request attributes outside of
an actual web request, or processing a request outside of the originally receiving thread?
If you are actually operating within a web request and still receive this message, your
code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use
RequestContextListener or RequestContextFilter to expose the current request.
Adding the org.springframework.web.context.request.RequestContextListener and its loader to web.xml and importing them into the page doesn't help either.
There is much about this on the web, but in my case it only happens on Cloud Foundry.
Cloud Foundry runs on Java 1.6, like my machine. The logs say the same as the quote above, with stack traces identical to what I've found on the web.
Any ideas? I'm stuck. I've spent the best of two days on this.
Thanks.
Adding compile ":webxml:1.4.1" to the plugins section of BuildConfig.groovy should fix that. Credit to http://support.cloudfoundry.com/entries/21371626-grails-mongodb-deployment-fails
I just created a new grails-app,
everything was fine until I decided
to install Spring Security Core.
After installing Spring Security Core
doing an s2-quickstart and hitting
grails run-app, it produced the
following error:
URI
/test1/
Class
java.lang.IllegalStateException
Message
No thread-bound request found: Are you referring to request attributes outside of an actual web request, or processing a request outside of the originally receiving thread? If you are actually operating within a web request and still receive this message, your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request.
Anybody know how to fix this?
I would really appreciate it if
you help. I have tried looking for
answers in other websites, however
I was unable to solve it. :)
BTW, I am using:
Spring Security Core 1.2.4
Grails 2.0.0.RC1
If you're using Maven, make sure you have this on your pom.xml:
<dependency>
<groupId>org.grails.plugins</groupId>
<artifactId>webxml</artifactId>
<version>1.4.1</version>
<scope>runtime</scope>
<type>zip</type>
</dependency>
and in BuildConfig,groovy:
runtime ":webxml:1.4.1"
That solved the issue for me with Grails 2.2.0.
This can happen if you're using an older version of Spring Security Core. I hit this when upgrading from grails 1.3.7 (and spring security 1.1.3) to grails 2.0.0. The fix was to change to spring-security-core 1.2 in application.properties:
plugins.spring-security-core=1.2
More info at http://jira.grails.org/browse/GPSPRINGSECURITYCORE-98 as suggested by 황현정.
Try to register a RequestContextListener listener in web.xml file.
File : web.xml
<web-app>
...
<listener>
<listener-class>
org.springframework.web.context.request.RequestContextListener
</listener-class>
</listener>
</web-app>