Castle.Windsor with RabbitMQ 4.0.0+, Issues with IEndpointResolver not resolving

295 views
Skip to first unread message

Adam O --

unread,
Sep 5, 2016, 8:08:49 AM9/5/16
to rabbitmq-users
Hi folks,

We've been using RabbitMQ client up to 4.0.0 without any problems, and since updating to 4.0.2 i'm getting some issues with a dependency failing while trying to resolve an IEndpointResolver.

Apparently this has appeared in v4+, and there is a DefaultEndpointResolver which would seem like a good candidate for the dependency to resolve to, but causes connection issues.

Googling returns very little information about how to use these new components. Does anyone have any information that could help me out?

Adam 

Michael Klishin

unread,
Sep 5, 2016, 8:32:12 AM9/5/16
to rabbitm...@googlegroups.com
Can you please at least post a transcript of what you are doing and the stack trace you are getting?

Here's why IEndpointResolver introduced:

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
MK

Staff Software Engineer, Pivotal/RabbitMQ

Adam O --

unread,
Sep 5, 2016, 8:58:46 AM9/5/16
to rabbitmq-users
Hi - apologies if my question was a little light. The failure occurs on this line after updating to 4.0.2 :-

this.connection = this.connectionFactory.CreateConnection();

"Exception thrown: 'Castle.MicroKernel.ComponentNotFoundException' in Castle.Windsor.dll. Additional information: No component for supporting the service RabbitMQ.Client.IEndpointResolver was found"


If I try to resolve this by adding a Registration for a DefaultEndpointResolver (passing in a AmqpTcpEndpoint)

var resolver = new DefaultEndpointResolver(new AmqpTcpEndpoint[]
{
    new AmqpTcpEndpoint(host, port, new SslOption
        {
            Enabled = false,
        } )
});
container.Register(Component.For<IEndpointResolver>().IsDefault().LifeStyle.Singleton.Instance(resolver));

I seem to get an error message which complains about resolving the IP address - 

No ip address could be resolved for [hostname here].

Bit stumped as how to resolve, any ideas on how to try and figure this one out would be greatly appreciated.



Adam O --

unread,
Sep 5, 2016, 9:02:56 AM9/5/16
to rabbitmq-users
Stack trace is simply - 

ConnectFailureException
{"Connection failed"}

RabbitMQ.Client
   at RabbitMQ.Client.Impl.SocketFrameHandler.Connect(ITcpClient socket, AmqpTcpEndpoint endpoint, Int32 timeout)

Karl Nilsson

unread,
Sep 5, 2016, 10:05:05 AM9/5/16
to rabbitm...@googlegroups.com
I am really not sure why Castle Windsor is complaining about the IEndpointResolver. There should be no reason to provide this as it the `EndpointResolverFactory` returns the default resolver by, uhm, default. Perhaps Castle provides some magic to try to wire up the factory function without anyone explicitly asking it to?


Can you try to connect without Castle and without overriding the EnpointResolverFactory? Does this work? If so then try it with your custom endpoint resolver?

Cheers
Karl

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Karl Nilsson

Staff Software Engineer, Pivotal/RabbitMQ

Adam O --

unread,
Sep 5, 2016, 10:23:48 AM9/5/16
to rabbitmq-users
Hey Karl,

I've already got a local repo of the source code and looked through thoroughly to understand what's going on, and thought that EndpointResolverFactory should be doing that job as you have explained. 

We've just been playing around with various things here to ascertain what is causing the problem. Very strange scenarios causing this error to appear.

I have a local RabbitMQ instance, and one in the Amazon cloud. If I connect locally (using 'localhost'), no problem. If I connect to the remote instance I get the exception :-

Exception thrown: 'System.ArgumentException' in RabbitMQ.Client.dll. No ip address could be resolved for [hostname here]

But, we have discovered that this ONLY happens if I have break points set to stop on Common Language Runtime Exceptions - if I put these back to default and execute everything works without issues. It seems enabling CLR debugging was causing the initial connection to fail in this way?

Very odd behaviour, also not sure if Castle may be responsible somehow?

Adam

Karl Nilsson

unread,
Sep 5, 2016, 11:32:18 AM9/5/16
to rabbitm...@googlegroups.com
Hmm currently when attempting a connection the RabbitMQ client first tries to connect using ipv6, if this fails it throws a (later caught) exception before trying ipv4. Perhaps having the debugger and CLR exceptions enabled interferes with the workflow. 

4.0.2 does, however, have a change in this area where it filters the resolved IPAddresses to match the IP version. Are you saying 4.0.1 does not exhibit this behaviour?

Cheers
Karl

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Adam O --

unread,
Sep 5, 2016, 12:06:20 PM9/5/16
to rabbitmq-users

We weren't seeing this behavior on 3.6.5, it's appeared since moving up into 4.0.2. I haven't tested 4.0.1.

I think we are happy to ignore this as it only appears under debug in certain circumstances. As long as you think it's OK to do this -
container.Register(Component.For<IEndpointResolver>().ImplementedBy<DefaultEndpointResolver>());

I'm not passing in a series of endpoints into the DefaultEndpointResolver constructor and this seems to allow me continue using Windsor in the same way I was in previous (3.6.5) versions. I'm assuming this won't be used anywhere as I can't see a single place where IEndpointResolver is being passed into a constructor as a dependency.

Adam


On Monday, 5 September 2016 16:32:18 UTC+1, Karl Nilsson wrote:
Hmm currently when attempting a connection the RabbitMQ client first tries to connect using ipv6, if this fails it throws a (later caught) exception before trying ipv4. Perhaps having the debugger and CLR exceptions enabled interferes with the workflow. 

4.0.2 does, however, have a change in this area where it filters the resolved IPAddresses to match the IP version. Are you saying 4.0.1 does not exhibit this behaviour?

Cheers
Karl
On 5 September 2016 at 15:23, Adam O -- <jersey...@gmail.com> wrote:
Hey Karl,

I've already got a local repo of the source code and looked through thoroughly to understand what's going on, and thought that EndpointResolverFactory should be doing that job as you have explained. 

We've just been playing around with various things here to ascertain what is causing the problem. Very strange scenarios causing this error to appear.

I have a local RabbitMQ instance, and one in the Amazon cloud. If I connect locally (using 'localhost'), no problem. If I connect to the remote instance I get the exception :-

Exception thrown: 'System.ArgumentException' in RabbitMQ.Client.dll. No ip address could be resolved for [hostname here]

But, we have discovered that this ONLY happens if I have break points set to stop on Common Language Runtime Exceptions - if I put these back to default and execute everything works without issues. It seems enabling CLR debugging was causing the initial connection to fail in this way?

Very odd behaviour, also not sure if Castle may be responsible somehow?

Adam

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To post to this group, send email to rabbitm...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Karl Nilsson

unread,
Sep 5, 2016, 12:33:01 PM9/5/16
to rabbitm...@googlegroups.com
If it makes your container happy then I can't see a reason not to do it. I am still surprised it is necessary however.

Cheers
Karl

To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages