New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Potential issue with JMX #227
Comments
Hi, Can you post (or gist) the entire stacktrace ? Also, is there an example to reproduce? Thanks |
|
Thanks! I see the issue now. |
Still need the code? I can post a fat-jar if you'd like |
Thanks, no I believe I have a grip on the issue. I think one of the components sets |
hmm. I don't set that in my components anywhere. |
bootstrap.yml
application.yml
|
Ok, thanks. I think I got it though. |
This will be addressed by a4fe3ef - you can try by rebuilding SCS master, or waiting a bit until CI publishes snapshots. |
Thanks! I'll check it out after CI cranks it through. |
Looks like the JMX issue is resolved, but that leads to an infinite fail on startup, preventing the startup of the springcloudbus. Stacktrace snippet:
|
Messages prior to stack dump:
|
OK, thanks for the update. Would it be possible to provide me with the fat jar? |
Do you have a place I can post it? It's large jar...still uses a lot of starters. |
Here is the head of the stacktrace dump:
|
Hi - made a few changes to Spring Cloud Stream - which removes the subsequent autoconfig. I suspect that it would resolve this issue as well. Can you try the latest snapshot build by any chance? |
Looks a little closer. However, now the problem seems to have shifted to the rabbitmq setup. The following is produced over and over again...
Also, the exchange that was previously getting created in rabbitmq never gets constructed, nor does the spring cloud bus queue. |
I think this is mostly an issue with the interaction with Spring Cloud Config - I'll give it a quick spin |
So, I narrowed it down a bit (we may want to close this issue & open a new one if you'd like.) Previously, we were able to use our own definition of the ConnectionFactory & have it picked up by the Autowire in the RabbitMessageChannelBinder. This no longer looks like the case, as the autowire is selecting the one that springboot makes - instead of the one we have independently created - though I can verify that ours has still been instantiated as a spring bean prior to the RabbitMessageChannelBinder setup. |
OK, thanks - that would be great. I think I have a fairly good idea on how to fix this, but this is not a JMX issue anymore. |
Have a new issue with spring-boot applications (e.g. spring-cloud-config-server & spring-cloud-eureka-server) where the same JMX bean is getting registered twice causing a failure.
Seems that the initial registration is coming from a call on the spring-boot app startup into
org.springframework.boot.admin.SpringApplicationAdminMXBeanRegistrar
and the later call comes from the ChannelBindingService.
Using the 1.0.0.BUILD-SNAPSHOT for spring-cloud-stream, the 1.1.0.BUILD-SNAPSHOT for the spring-cloud-starter, and the 1.3.0.BUILD_SNAPSHOT for spring-boot
Stacktrace for ref of the fail on the ChannelBindingService call to afterPropertiesSet():
The text was updated successfully, but these errors were encountered: