How to start Docker Axon server in development mode - spring

I'm new to Axon and Docker and I would like to start axon server in Docker using developmnent mode in order to clear events as I'm in the process of building a system and my events and commands change often.
I read on Axon documentation that a certain property axoniq.axonserver.devmode.enabled (defaults to false) has to be set. I also know that Axon uses spring boot, so I guess I would need to somehow access the axonserver.properties on Docker, but here is the problem, i don't know how.
I would be thankful if anyone could explain how to change this configuration.

Fortunatelly Axon has been publishing blogs about running axon-server and one of them, they teach how to run it on docker =)
Blog post: https://axoniq.io/blog-overview/running-axon-server-in-docker
The important part, in your case, is here:
A third directory, not marked as a volume in the image, is important for our case: If you put an “axonserver.properties” file in “/config”, it can override the settings above and add new ones:
Which means, you can create your axonserver.properties in this directory with the desired property (axoniq.axonserver.devmode.enabled=true) and it will pick it up from there!
On the other hand, you can also set the environment variable: AXONIQ_AXONSERVER_DEVMODE_ENABLED to true.
Hope it helps.

Related

Persist Quarkus devservices database

Is there a way of persisting Quarkus devservices databases? Maybe a way of using volumes, but I can not find any reference. I am thinking on something like a property (non existing) quarkus.datasource.devservices.volume=some_volume that will reuse some_volume existing volume with the spin Docker container.
Maybe what you can do for now is, disable database startup from dev-services (see link 3 below) and add a QuarkusTestResource on your test class and startup your own docker image with a volume mount to your disk.
And the next time you startup your test, the data should be available as long as it points to the same volume mount. Also make sure that you don't use TestTransaction, otherwise the transaction will be rollbacked at the end of the test.
Maybe these links can help you:
cheat sheat: continious testing
cheat sheat: dev-services
dev-service guide

What is the difference between ddl-auto and hbm2ddl.auto?

Every time I try to start "Spring Boot Dashboard" from VSCode I get an error while using the following command.
spring.jpa.hibernate.ddl-auto=update (Doesn't Work)
However, I managed to find this line here on stack overflow that made it work. The problem is I don't know the difference and how will it impact my production.
spring.jpa.hibernate.hbm2ddl.auto=update (Works)
Any sort of help would be more than appreciated.
From this Link
spring.jpa.hibernate.ddl-auto This is actually a shortcut for the "hibernate.hbm2ddl.auto" property.
Defaults to "create-drop" when using an embedded database and no schema manager was detected. Otherwise, defaults to "none".
From this Stackoverflow Link
In production, it's often highly recommended you use none or simply don't specify this property. That is because it's common practice for DBAs to review migration scripts for database changes, particularly if your database is shared across multiple services and applications.

Clickhouse server failed to restart because of LowCardinality setting

I tried to play with LowCardinality setting, I got a message saying that this is an experimental feature and I have to SET allow_experimental_low_cardinality_type = 1 in order to use it.
I executed this command inside clickhouse-client and then I restarted the server. But I got
clickhouse-server.service: Unit entered failed state
Now I am trying to find out how to disable this setting and make my clickhouse-server start again.
Can you help with this please ?
PS: The version I use is the 18.12.17 and I installed it on Linux Ubuntu 16.04
ClickHouse has different layers for settings. If you used SET <setting> = <value> then you set it for current session. You don't need to restart ClickHouse. Please, take a look here.
I suppose you faced with another problem during starting your server. There a bunch of reasons why. So, firstly try to recollect what were done in configs since last restart (because you have just applied changes by restarting server).
Digging into logs also an awesome idea. Don't hesitate to check other similar issues on github.com, for example like this one

ClassPath resource not found

I'm trying to deploy my Spring Boot based application to a CloudControl container.
I've added the mysql.free add-on and configured it through my application.properties:
spring.datasource.driverClassName=com.mysql.jdbc.Driver
spring.datasource.max-active=1
spring.datasource.max-idle=1
spring.datasource.min-idle=1
spring.datasource.initial-size=1
spring.datasource.url=jdbc:mysql://${MYSQLS_HOSTNAME}:${MYSQLS_PORT}/${MYSQLS_DATABASE}
spring.datasource.username=${MYSQLS_USERNAME}
spring.datasource.password=${MYSQLS_PASSWORD}
On my local development system, everything works perfectly fine, but on the CloudControl container, the app won't start.
I added the StackTrace here. I'm trying to solve the problem for days, but I am not able to solve it by my own.
Spring apps are very memory consuming and the mysqls.free addon allows only a limited number of parallel connections. Although your Stacktrace doesn't show any of these problems. It's hard to solve this issue without more context like logs or environment settings.
The following commands may help:
cctrlapp app_name/default log error # shows startup log
cctrlapp app_name/default addon.creds # shows DB credentials
I've uploaded some spring-boot example code at https://github.com/cloudControl/spring-boot-example-app which I've tested on cloudControl today.
Please take a look at the configuration there. If you want to deploy it, make sure your container has memory size >= 768mb.
cctrlapp app_name/default deploy --memory 768MB
If you still have issues, please contact cloudControl support to help you.

How does one run Spring XD in distributed mode?

I'm looking to start Spring XD in distributed mode (more specifically deploying it with BOSH). How does the admin component communicate to the module container?
If it's via TCP/HTTP, surely I'll have to tell the admin component where all the containers are? If it's via Redis, I would've thought that I'll need to tell the containers where the Redis instance is?
Update
I've tried running xd-admin and Redis on one box, and xd-container on another with redis.properties updated to point to the admin box. The container starts without reporting any exceptions.
Running the example stream submission curl -d "time | log" http://{admin IP}:8080/streams/ticktock yields no output to either console, and not output to the logs.
If you are using the xd-container script, then the redis.properties is expected to be under "XD_HOME/config" where XD_HOME points the base directory where you have bin, config, lib & modules of xd.
Communication between the Admin and Container runtime components is via the messaging bus, which by default is Redis.
Make sure the environment variable XD_HOME is set as per the documentation; if it is not you will see a logging message that suggests the properties file has been loaded correctly when it has not:
13/06/24 09:20:35 INFO support.PropertySourcesPlaceholderConfigurer: Loading properties file from URL [file:../config/redis.properties]

Resources