Dan,

rather unique, but not quite unique.

We're also having an WinForms application on a desktop image, which
can be used by more than on user with the same windows login through RDP.
The reason for this is that the WinForms app uses a service on another machine, and MSMQ traffic back from the service is allowed for the IP adress of this desktop image.

It's _not_ allowed for regular desktops, which are in another IP range.

Dynamically creating the input queue could work for us.
What would be the reason for you to use an image for deployment of the WinForms app?
Would it be possible to share your code for dynamically creating the input queues for nServiceBus?

Kind regards,
Richard Gremmen

(really enjoying this nServiceBus group)

--- In nservicebus@yahoogroups.com, Dan Ports <danports@...> wrote:
>
> Sorry, I just realized my last message was a bit vague. What I meant to say
> is that if you delete the queue while a bus worker thread is trying to do a
> Receive operation on it, the delete succeeds but the Receive operation
> throws a MessageQueueException. What's more, this exception is a bit hard to
> catch because it happens on a worker thread, so it bubbles up to our
> application logging system and sends us some nasty emails.
> Another solution might be to swallow some exceptions in MsmqTransport after
> Dispose() is called.
>
> And yes, you're right about our circumstances being rather unique.
>
> Thanks,
> Dan
>
> On Fri, Mar 13, 2009 at 10:19 PM, Udi Dahan

> <thesoftwaresimplist@...>wrote:

>
> > Well, one solution could be to loop on deleting the queue until its
> > successful after calling dispose. Not very pretty, but workable under your
> > (I'd say unique) circumstances.
> >
> >
> >
> > -- Udi
> >
> >
> >
> > *From:* nservicebus@yahoogroups.com [mailto:nservicebus@yahoogroups.com] *On
> > Behalf Of *Dan Ports
> > *Sent:* Wednesday, March 11, 2009 6:41 PM
> >
> > *To:* nservicebus@yahoogroups.com
> > *Subject:* Re: [nservicebus] How to stop message processing?
> >
> >
> >
> > The problem is that if you delete the queue while a bus worker thread is
> > trying to do a Receive() operation on it, you get a MessageQueueException.
> >
> >
> >
> > We don't really care if we lose messages while shutting down since the
> > messages will just be trying to update various GUI widgets.
> >
> >
> >
> > Dan
> >

> > On Wed, Mar 11, 2009 at 12:31 PM, Udi Dahan <thesoftwaresimplist@...>

> > wrote:
> >
> > If that's what you're doing, why do you care if you delete the queue before
> > a message has completed processing?
> >
> > I mean, either you'll lose the message or delete the queue with the message
> > still in it. The result is the same, no?
> >
> >
> >
> > -- Udi
> >
> >
> >
> > *From:* nservicebus@yahoogroups.com [mailto:nservicebus@yahoogroups.com] *On
> > Behalf Of *Dan Ports
> > *Sent:* Wednesday, March 11, 2009 4:11 PM
> >
> >
> > *To:* nservicebus@yahoogroups.com
> > *Subject:* Re: [nservicebus] How to stop message processing?
> >
> >
> >
> > haha, yeah, maybe I should have explained that. Here's the scenario:
> >
> >
> >
> > We have a WinForms app with some pub-sub functionality that customers
> > access via RDP. This means we often have multiple app instances running
> > simultaneously on our server. This rules out using a single input queue for
> > the app. Reusing input queues seems fraught with possible race conditions,
> > and you still have to dynamically create those queues in case you run out of
> > them. Neither can we use a stable identifier like the Windows user name for
> > the queue names because Windows Server will sometimes allow multiple RDP
> > sessions for a single user name.
> >
> >
> >
> > So, we create an input queue with a name like Guid.NewGuid() on app
> > startup, and shutdown the bus and delete the queue on exit. This approach
> > has worked well for us, but I would certainly like to hear any other options
> > we might have.
> >
> >
> >
> > Dan
> >

> > On Tue, Mar 10, 2009 at 7:15 PM, Udi Dahan <thesoftwaresimplist@...>

> > wrote:
> >
> > > I wanted to delete the input queue the bus was using when the application
> > closed
> >
> >
> >
> > I'd really like to hear your reasons why.
> >
> >
> >
> > Thanks,
> >
> > -- Udi
> >
> >
> >
> > *From:* nservicebus@yahoogroups.com [mailto:nservicebus@yahoogroups.com] *On
> > Behalf Of *Dan Ports
> > *Sent:* Friday, March 06, 2009 11:26 PM
> >
> >
> > *To:* nservicebus@yahoogroups.com
> > *Subject:* Re: [nservicebus] How to stop message processing?
> >
> >
> >
> > BTW, it would be helpful if Dispose (or some overload of the hopefully
> > forthcoming Stop method) waited until all worker threads exited before
> > returning. I needed this in one of my nServiceBus applications because I
> > wanted to delete the input queue the bus was using when the application
> > closed. I have a patch for this that has been in production for a few
> > months, and I'll clean it up and send it in if anyone's interested.
> >

> > On Fri, Mar 6, 2009 at 4:06 PM, Udi Dahan <thesoftwaresimplist@...>

> > wrote:
> >
> > Let me just say how wonderful it is to hear everyone.
> >
> > The question that does seem to have been left unanswered is "what happens
> > on Dispose?"
> >
> >
> >
> > Dispose asks each worker threads to finish any work that its currently
> > doing and then end.
> >
> > In other words, it is a graceful exit.
> >
> >
> >
> > If you are concerned about a message getting lost, set your endpoint up as
> > transactional irrespective of what Dispose might do. That makes it safe in
> > event of an abrupt server/process crash. If you do this, you can simply kill
> > processes to get them to stop and have everything be safe.
> >
> >
> >
> > All that being said, adding a "Stop" method is a good idea and it will call
> > Dispose as suggested.
> >
> >
> >
> > In order to understand the usage scenario of ChangeNumberOfWorkerThreads,
> > we need to discuss the distributor (search the archives for some
> > background). When you'd like to bring down a worker node that is part of a
> > distributor's farm, you want to cause the distributor to stop sending any
> > more new messages to that node, so that the rest of the load will get
> > balanced between the remaining nodes. Since each node tells the distributor
> > when its ready for more work, we need to get the node to stop doing that.
> >
> >
> >
> > Abruptly bringing the number of worker threads to zero will achieve that,
> > but we still need to finish processing any messages left in that node's
> > input queue. Gradually bringing down the number of worker threads will
> > result in the number of outstanding messages in the input queue going down
> > as well, to the point that you're down to one message and one thread. At
> > that point, you send the final message to bring threads to zero, let it be
> > processed, and take the server offline. At that point, all load is being
> > distributed between remaining machines without having any messages get stuck
> > or lost.
> >
> >
> >
> > Does that make sense?
> >
> >
> >
> > --
> >
> > Udi Dahan - The Software Simplist
> >
> >
> >
> > *From:* nservicebus@yahoogroups.com [mailto:nservicebus@yahoogroups.com] *On

> > Behalf Of *jiho.han@...
> > *Sent:* 06 March 2009 16:23

> >
> > - Show quoted text -
> >
> >
> > *To:* nservicebus@yahoogroups.com
> > *Subject:* Re: [nservicebus] How to stop message processing?
> >
> > - Show quoted text -
> >
> >
> >
> >
> > +1
> >
> > you're starting and stopping a windows service - seems like a perfect
> > places to construct and destruct, respectively. You wouldn't expect web
> > server to "pause" and have any resources hanging around when you stop it.
> >
> > just a minor observation from API standpoint...
> > looks to me a matching Stop for a Start would be best. Like Stream's
> > Open/Close.
> > And Stop can just call Dispose, like Close calls Dispose.
> >
> > Jiho
> >
> > nservicebus@yahoogroups.com wrote on 03/06/2009 07:55:09 AM:
> >
> > > Hmmm...ok.
> >
> > > When a windows service starts and stops the idea is normally that Start
> > > method in the service code will set up any resources required to get the
> > > service started and the Stop method will execute any resource disposal
> > > before the process or thread the service is executing is terminated. As
> > a
> > > result the bus.Start and bus.Dispose methods respectively make perfect
> > sense
> > > to call in in the service's Start and Stop methods.
> >
> > > If you want to pause a windows service and resume it then that's another
> > > situation. In that case you may want to tell the bus to stop processing
> > > messages off it's input queue, which could be done by it sending itself a
> > > control message indicating the number of worker threads to run, as per
> > the
> > > earlier part of the conversation.
> >
> > > Are you looking for a way to ensure the bus gets stopped but will do so
> > > gracefully, allowing the current message to finish processing before
> > > stopping and disposing? I could certainly see a Pause or Stop method on
> > the
> > > bus that stopped it listening for new messages but finished processing
> > > existing ones and didn't release resources (thereby allowing start to be
> > > called again) might make some sense in that case...
> >
> > > Cheers,
> >
> > > Symon.
> >
> > > Symon Rottem
> > > http://blog.symbiotic-development.com
> >
> > >

> > > On Fri, Mar 6, 2009 at 1:33 PM, Michael(me) <micbiz42@...>

> > wrote:
> >
> > > > I think we are sort of making progress J
> > > >
> > > >
> > > >
> > > > Let me try to clarify.
> > > >
> > > > I have a windows service that is a consumer i.e. it has message
> > handlers
> > > > that are invoked when messages arrive.
> > > >
> > > > A windows service has start and stop methods. I want to know what code
> > to
> > > > put in these methods to control the processing of the messages
> > arriving.
> > > >
> > > > I could put the bus initialisation code in Start(), and call Dispose()
> > in
> > > > Stop(). But what happens if there are messages currently being handled
> > when
> > > > Dispose() is called? It also seems a bit heavy: create a bus, delete a
> > bus.
> > > >
> > > >
> > > >
> > > > I don't want the service to send a message to itself (as described
> > below) –
> > > > seems wasteful.
> > > >
> > > > Also, changing the thread count as a way of starting/stopping the bus
> > is
> > > > not a particularly expressive design.
> > > >
> > > > There's got to be a better way.
> > > >
> > > >
> > > >
> > > > IBus.Start and IBus.Pause sound good to me.
> > > >
> > > >
> > > >
> > > > But thanks for responding.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > *From:* nservicebus@yahoogroups.com [mailto:
> > nservicebus@yahoogroups.com] *On
> > > > Behalf Of *Symon Rottem
> > > > *Sent:* 06 March 2009 12:11
> > > >
> > > > *To:* nservicebus@yahoogroups.com
> > > > *Subject:* Re: [nservicebus] How to stop message processing?
> > > >
> > > >
> > > >
> > > > Are you actually looking for a way to start and stop a windows service
> > or
> > > > to control the bus?
> > > >
> > > > Udi pointed out the ChangeNumberOfWorkerThreadsMessage method of
> > > > controlling the bus - you send this from whatever controlling
> > application
> > > > you use and send it to the specific service you want to control. In
> > this
> > > > message you can specify the number of worker threads as 0 and the
> > result
> > > > will be that the bus will stop processing any new messages until
> > another
> > > > message is received increasing the number of threads by sending another
> > > > ChangeNumberOfWorkerThreadsMessage message to the service.
> > > >
> > > > This is the exact equivalent of pausing and resuming the bus.
> > > >
> > > > Symon.
> > > >
> > > > Symon Rottem
> > > > http://blog.symbiotic-development.com
> > > >

> > > > On Fri, Mar 6, 2009 at 12:47 PM, Michael(me) <micbiz42@...

> > >
> > > > wrote:
> > > >
> > > > Udi, thanks for the response, but Rimas' suggestion is what I need.
> > > >
> > > > Surely this has come up before? There must be lots of people hosting
> > their
> > > > endpoints in Windows services. How do they control those services?
> > Surely
> > > > with Start / Stop?
> > > >
> > > >
> > > >
> > > > Anyone else like to chip in?
> > > >
> > > > Thanks
> > > >
> > > > Michael
> > > >
> > > >
> > > >
> > > > *From:* nservicebus@yahoogroups.com [mailto:
> > nservicebus@yahoogroups.com] *On
> > > > Behalf Of *Rimaeys Zavisius
> > > > *Sent:* 06 March 2009 11:04
> > > > *To:* nservicebus@yahoogroups.com
> > > > *Subject:* Re: [nservicebus] How to stop message processing?
> > > >
> > > >
> > > >
> > > > hi.
> > > >
> > > > the methods Pause & Resume on bus would be nice.
> > > >
> > > > Rimas Z.
> > > >
> > > > On Fri, Mar 6, 2009 at 12:25, Udi Dahan

> > > <thesoftwaresimplist@...<thesoftwaresimplist%40gmail.com>>

> > > > wrote:
> > > > > There are 3 ways to stop a bus from processing messages.
> > > > >
> > > > > One is to simply kill the process.
> > > > > The second is to call bus.Dispose();
> > > > > The third is to send it a ChangeNumberOfWorkerThreadsMessage with
> > zero as
> > > > a
> > > > > parameter, (this requires the grid handlers to be active, which is
> > the
> > > > > default when using LoadMessageHandlers as opposed to
> > > > > SetMessageHandlersFromAssembliesInOrder where it is not).
> > > > >
> > > > > Does that answer your question?
> > > > >
> > > > > --
> > > > > Udi Dahan - The Software Simplist
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: nservicebus@yahoogroups.com <nservicebus%40yahoogroups.com
> > >[mailto:
> > > > nservicebus@yahoogroups.com <nservicebus%40yahoogroups.com>]
> > > > >> On Behalf Of Michael Mayne
> > > > >> Sent: 06 March 2009 10:04
> > > > >> To: nservicebus@yahoogroups.com <nservicebus%40yahoogroups.com>
> > > > >> Subject: [nservicebus] How to stop message processing?
> > > > >>
> > > > >> Hi,
> > > > >>
> > > > >> I'm just getting started with NSB.
> > > > >>
> > > > >> I'm hosting a subscriber in a Windows service (on Vista for dev).
> > I'd
> > > > >> like it to honour to start / stop methods on the service:
> > > > >>
> > > > >> When I stop the service I want it to stop processing messages and
> > vice
> > > > >> versa.
> > > > >>
> > > > >>
> > > > >>
> > > > >> When the service starts it initializes using something like this:
> > > > >>
> > > > >>
> > > > >>
> > > > >> var bus = NServiceBus.Configure.With()
> > > > >>
> > > > >> .SpringBuilder()
> > > > >>
> > > > >> .XmlSerializer()
> > > > >>
> > > > >> .MsmqTransport()
> > > > >>
> > > > >> .IsTransactional(false)
> > > > >>
> > > > >> .PurgeOnStartup(false)
> > > > >>
> > > > >> .UnicastBus()
> > > > >>
> > > > >> .ImpersonateSender(false)
> > > > >>
> > > > >> .SetMessageHandlersFromAssembliesInOrder(
> > > > >>
> > > > >> typeof(EventMessageHandler).Assembly
> > > > >>
> > > > >> )
> > > > >>
> > > > >> .CreateBus()
> > > > >>
> > > > >> .Start();
> > > > >>
> > > > >>
> > > > >>
> > > > >> i.e. the message handlers get hooked up.
> > > > >>
> > > > >> How do I prevent the message handlers from being invoked when the
> > > > >> service is stopped?
> > > > >>
> > > > >>
> > > > >>
> > > > >> Thanks
> > > > >>
> > > > >> Michael
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> No virus found in this incoming message.
> > > > >> Checked by AVG - www.avg.com
> > > > >> Version: 8.0.237 / Virus Database: 270.11.3/1970 - Release Date:
> > > > >> 03/04/09 19:17:00
> > > > >
> > > > >
> > > >
> > > > No virus found in this incoming message.
> > > > Checked by AVG - www.avg.com
> > > >
> > > > Version: 8.0.237 / Virus Database: 270.11.5/1979 - Release Date:
> > 03/05/09
> > > > 19:32:00
> > > >
> > > >
> > > >
> > > > No virus found in this incoming message.
> > > > Checked by AVG - www.avg.com
> > > > Version: 8.0.237 / Virus Database: 270.11.5/1979 - Release Date:
> > 03/05/09
> > > > 19:32:00
> > > >
> > > >
> > > [attachment "C.htm" deleted by Jiho HAN/US/AMERICAS/GROUP]
> >
> >
> >
> >
> >
> > This message and any attachments (the "message") is intended solely for
> >
> >
> >
> >
> >
> > the addressees and is confidential. If you receive this message in error,
> >
> > please delete it and immediately notify the sender. Any use not in accord
> >
> > with its purpose, any dissemination or disclosure, either whole or partial,
> >
> > is prohibited except formal approval. The internet can not guarantee the
> >
> > integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
> >
> >
> >
> > not therefore be liable for the message if modified. Please note that certain
> >
> > functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.
> >
> > No virus found in this incoming message.
> > Checked by AVG - www.avg.com
> > Version: 8.0.237 / Virus Database: 270.11.3/1970 - Release Date: 03/04/09
> > 19:17:00
> >
> >
> >
> > No virus found in this incoming message.
> > Checked by AVG - www.avg.com
> > Version: 8.0.237 / Virus Database: 270.11.3/1970 - Release Date: 03/04/09
> > 19:17:00
> >
> >
> >
> >
> >
> >
> >
>