Running Subscription Service under 2.0 GA

[Brian Z]

Hello,

First of all, congratulations on the GA release! I downloaded it
yesterday and tried a few simple examples in it. So far, I have been
unable to connect to the subscription service using the 2.0.0.5 GA
release assemblies.

I am using the following code to create the service bus:

bus = ServiceBusFactory.New(sbc =>
{
sbc.UseMsmq();

sbc.VerifyMsmqConfiguration();

sbc.UseSubscriptionService("msmq://localhost/mt_subscriptions");

sbc.ReceiveFrom("msmq://localhost/test_pub");
});

When I run this it contacts the subscription service correctly and I
get a response "SubscriptionRefresh" message in the test_pub queue
that just sits in the queue. The process eventually throws an error
of "Timeout waiting for subscription service to respond". I don't see
anything in the log files that indicates a problem other than the
process waiting for a response from the service.

If I remove the 2.0.0.5 assemblies and use the 2.0.0.2 assemblies from
the previous release, this works just fine and the process consumes
the message. Was there a change to the configuration process for the
subscription service in the new release that I am not seeing, or I am
missing something else?

Thanks,
Brian

[Chris Patterson]

Seems like this might be an issue, I'll check into it.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To post to this group, send email to masstrans...@googlegroups.com.
To unsubscribe from this group, send email to masstransit-dis...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/masstransit-discuss?hl=en.

[Brian Z]

I tried to dive into the code to take a look at this, and it's looking
like it is probably a bug, but I haven't been able to track it down.
As a side note, when I turned on the control queue in the
configuration, the control queue was being registered with the service
as both the control and data uri.

Everything works fine for me if I use the multicast subscription
client. I've noticed that most of the examples and samples use the
multicast client as well. Is this the direction that MassTransit is
going to go in the future?

We are currently looking for a service bus solution for our company,
and the main thing that we really like about MassTransit is the
flexibility of the subscription service. We really don't want to be
multicasting on our network, though, so if you see that as being, or
becoming in the future, the main way of configuring MassTransit, that
will probably impact our decision.

Thanks,
Brian

[Dru Sellers]

Hi Brian,

I know chris is super busy and but I trust he will crush it when he gets a moment. Any failing unit tests or repro steps you can give us will help dramatically.
As far as direction of MT, I would say that its actually towards RabbitMQ. We plan to support MSMQ both Runtime based subscriptions and Multicast Subscriptions. But energy and growth is most likely to happen on RabbitMQ versus MSMQ.

@chris: would you agree?

-d

Thanks,
Brian

[Brian Z]

Thanks Dru, that's good to know.

As far as steps to reproduce, I am doing the following. I have the
MassTransit subscription service for the current release (2.0.0.5) up
and running. I can run publishers/subscribers from the previous
release (2.0.0.2) running against it and working just fine. I cannot
get a publisher running the current release to work with the
subscription service of the current release.

The entire code of my publisher is as follows:

class Program
{
public static void Main()
{
IServiceBus bus = null;
try
{

bus = ServiceBusFactory.New(sbc =>
{
sbc.UseMsmq();

sbc.VerifyMsmqConfiguration();

sbc.UseSubscriptionService("msmq://localhost/mt_subscriptions");

sbc.ReceiveFrom("msmq://localhost/test_pub");
});

Console.WriteLine("Type a message to send: ");
string input = Console.ReadLine();
bus.Publish(new TestMessage() { Text = input });
}
finally
{
if(bus != null)
bus.Dispose();
}
}
}

This will always timeout on the ServiceBusFactory.New line with the
exception "Timeout waiting for subscription service to respond". If I
look in the test_pub queue, I can see the SubscriptionRefresh message
sitting there waiting to be consumed. If I remove the references to
the current release and replace them with the references to the
previous release, it works correctly.


From looking in the MassTransit code, I can guess the following:

The exception is coming from the SubscriptionClient class in the
constructor. It's waiting for that SubscriptionRefresh message, but
it's not getting it.

This constructor is being called when the Build() method on the
ServiceBusBuilderImpl class calls RunBusServiceConfigurators(). This
is right before the bus.Start() call.

Until the bus is started, no messages on that queue get read. So the
SubscriptionClient can't get that SubscriptionRefresh message.

This appears to be the problem from what I can gather from the code,
but I'm not sure how it needs to be corrected. I'm sorry I can't be
of more help. Of course, if there's a configuration change I need to
make from the previous version to the current one, that would explain
it.

Thanks,
Brian

[Dru Sellers]

Ok thanks. I will try and reproduce.

-d

[Brian Z]

Have either of you gotten a chance to take a look at this? I'd really
like to know if this is a problem on my end so I can at least narrow
down where the problem is.

Thanks,
Brian

On Sep 22, 4:03 pm, Dru Sellers <d...@drusellers.com> wrote:
> Ok thanks. I will try and reproduce.
>
> -d
>

[Chris Patterson]

Are you running transactional queues on your services but non-transactional for the subscription service? There is a bug in GA related to using a mix of transactional and non-transactional queues.

[Brian Z]

Chris,

Thank you! It looks like that was part of the key to getting
MassTransit working again for me. After playing with this for a bit,
I have discovered that the mass transit subscription service will work
for me if I do the following:

Turn on the control queue option (.UseControlBus())

Make sure all the queues are transactional or all the queues are non-
transactional, including the queue used for the subscription service.

If any queues are deleted (such as you would do to change them from
non-transactional to transactional, the service must be restarted or
it won't work even if all the other settings are right.

The last one, restarting the service, was what I didn't pick up on
right away. I did this the first time I tried transactional queues
and then switched them to non-transactional to see if those would
work, and was unable to get this to work at all even after putting
everything back the way it was until I restarted the service again.

It appears that the control queue is required for MassTransit to work
with the subscription service for me. Another odd thing is that when
I look in the DB tables at my subscription clients, I notice that the
control queue is used for both the control Uri and the data Uri
value. Is this expected behavior?

Thank you again for the help!
Brian