When a BuildBot slave has several builders, if the BuildSlave is not IDLE - how can we know which of the builders is the one that keeps the BuildSlave busy?
In the web UI's home page you can see the build logs
and when selecting a specific build there is detail of builder and worker/slave
form this you can figure out what's going on
Related
I would like to develop a Kafka connector but for test quickly I would like reload the plugin without reload the container in my docker stack. Is there a way to do it?
Actually I compile the connector and i move the jar file in a folder binded on the container kafka connect. After move the file I reload the container.
Thanks in advance.
It's not possible to "hot swap" plugins; they are only scanned at startup of the Connect worker process, after the CLASSPATH is also scanned.
You should use unit/integration tests for "quickly testing". If that's not enough, then connect-standalone can be used rather than containers
I'm running a development environment for Play Framework 2.5.x in a Docker container. The application works, and I can view it on my browser through the shared port. However, the auto-update feature does not work.
From research I've learned this is because Play's JNotify doesn't poll file changes in shared folders. I've tried the solution to this problem, which is simply polling at a time interval by adding the following to build.sbt
PlayKeys.fileWatchService := play.runsupport.FileWatchService.sbt(pollInterval.value)
After making this change (and making sure it was pushed through the shared folder), using activator run successfully compiles and runs the server.
[info] Done updating.
--- (Running the application, auto-reloading is enabled) ---
[info] p.c.s.NettyServer - Listening for HTTP on /0:0:0:0:0:0:0:0:9000
(Server started, use Ctrl+D to stop and go back to the console...)
I can view it in my browser. However, on changing a file, no recompilation happens and refreshing doesn't change anything. Stopping and starting the server however does show the change.
I think I may know why, but I don't know how to solve it. I've read that using activator ~run supposedly starts the server, but uses SBT instead of activator. When I use this command to start the server, it hangs at:
[info] Set current project to example-user-app in build file:/home/example-user/example-user-app)
I am using following command to deploy code to my AEM instance "mvn clean install -Daem.host=localhost -Daem.port=1202 -Dmaven.test.skip=true
"
After deployment pages are taking too long to load at least 7 mins.
I found No errors/Exceptions in error log.
There could be couple of factors causing this slowness -
Amount of memory allocated to AEM instance, default setting is - CQ_JVM_OPTS='-server -Xmx1024m -XX:MaxPermSize=256M -Djava.awt.headless=true' which is actually not sufficient for optimal performance. I have been using double of this configurations and sometimes even more.
When you deploy your package with code, the bundles are processed and services are registered. Depending on number of services/components being registered the time can go up. Sometimes there are hooks within code that cause few system level bundles to cycle as well, if that happens it would actually cause all the other bundles dependent on system bundle to cycle and registering the services again.
your code deployment could be triggering some workflow that either consumes lot of resources or is causing delayed activation on your bundle. The first scenario could happen if your deployment has something like images which when deployed causes OOTB image workflow to trigger (there could be other based on your code). Second scenario could be that you have bundle activator either waiting for another bundle which gets deployed later (and/or stays installed and not active) or you are building some sort of caching that waits for pages to be deployed and processed. There are countless such scenarios that can cause this issue.
What you could do is check the status of the bundles in /system/console/bundles pre and post deployment you can identify bundle related issues there. Another thing you could try is to do selective deployment of the code to figure out what module is causing issue that then dive deeper in to that module.
Also look at recent request logs to identify the flow of page load to see if there are services, filters etc in picture that are causing delays.
Let me know if any of this approach helps you identify the root cause and in case you need further help, will be here to assist.
I am trying to use eclipse kepler for Java EE 7.I already installed JBoss Tools and added JBoss Wildfly successfully as a server. However my changes are not automatically deployed. Is there anyway the app can be deployed automatically just as when using glassfish?
Using Eclipse, click twice on your WildFly Server to edit the following properties:
Publishing: choose "Automatically publish after a build event". I like to change the publishing interval to 1 second too.
Application Reload Behavior: check the "Customize application reload ..." checkbox and edit the regex pattern to \.jar$|\.class$
That's it. Good luck!
Both #varantes and #Sean are essentially correct, but these answers are not full.
Unfortunately the only way in a Java server environment to have full, zero-downtime hot deployment is to use paid JRebel or free spring-loaded tool.
But for small project there are some ways to speed up work by partial hot-deployment. Essentially:
When enabled option Automatically publish when resource change
then changes inside *.html, *.xhtml files are immediately
reflected as soon as you refresh the browser.
To make hot deployment work for *.jsp files too, then you should
inside ${wildfly-home}/standalone/configuration/standalone.xml
make following change:
<jsp-config/>
replace with:
<jsp-config development="true"/>
restart the server and enjoy hot deployment of web files.
But when modifying *.java source files, then only partial hot deployment is possible. As #varantes stated in his answer, enabling Application Reload Behavior with regex pattern set to \.jar$|\.class$ is an option, but has serious downside: whole module is restarted, thus:
It takes some time (depending on how big is a module).
Whole application state is lost.
So personally, I discourage this solution. JVM supports (in debug mode) code-swapping for methods' bodies. So as long as you are modifying only bodies of existing methods, you are at home (zero downtime, changes are reflected immediately). But you have to disable automatic publishing inside server settings otherwise the application's state will still be destroyed by that republish.
But if you are heavily crafting Java code (adding classes, annotations, constructors) then unfortunately I can only recommend set publishing into Never publish automatically (or shutdown server) and when you finish your work in Java files, then restart by hand your module (or turn-on server). Up to you.
It works for small Java projects, but for bigger ones, JRebel is invaluable (or just spring-loaded), because all approaches described above are not sufficient. Also because of such problems, solutions like Rails/ Django /Play! Framework gained so huge popularity.
I am assuming you are using the latest version of Wildfly (8.0 Beta 1 as of writing).
In the standalone.xml config file, look for <jsp-config/>. Add the attribute development="true" and it should hot-deploy. The resulting config will look like this:
<jsp-config development="true"/>
Add attributes (development, check-interval, modification-test-interval, recompile-on-fail) in configuration file in xPath = //servlet-container/jsp-config/
<servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only">
<jsp-config development="true" check-interval="1" modification-test-interval="1" recompile-on-fail="true"/>
</servlet-container>
(It works in WildFly-8.0.0.Final)
Start server in debug mode and It will track chances inside methods. Other changes It will ask to restart the server.
Is is possible to 'unleash', or whatever, a process in Eclipse that you've been debugging, or simply started with 'run'? Would be nice. After such an 'unleash-ment', the unleashed process should not die when Eclipse is shut down, and should be removed from the debug view, to avoid accidentally killing it. Essentially, become a regular application process.
thanks, -j
There is no such command/option in Eclipse and it might not even possible depending on the OS. If you want a Java process to survive the end of Eclipse, you must start it outside.
It's sad that, after more than a decade, creating standalone processes in Java is still so painful. There is the -jar option but there is no way to have more than a single main() method this way, few people know how to build a working classpath when starting your app this way.