in reference to #3. What about the SynchronizationContext? Jeremy Miller wrote a MSDN article which touches on the subject. You can use the context to marshal the processing back to the UI thread.
On Sep 29, 6:22 am, Ayende Rahien <[email protected]> wrote: > inline > > On Tue, Sep 28, 2010 at 10:18 AM, John J <[email protected]> wrote: > > > Areas I am struggling with are: > > > 1. When my client application starts up, I do not want to process any > > messages on the input queue. (Another hint that maybe I am trying to > > use the wrong tool?). In NServiceBus there is a simple way to > > configure a client to purge its input queue on startup, but I can't > > find a straightforward way to do this in ESB. > > You can do that by manually purging the queue. > The NSB method is mostly used for development, and I consider it dangerous, > which is why it isn't included. > > Why do you want to clear the queue? > > > 2. Is there a way to easily unsubscribe everything? If somebody shuts > > down their desktop application and does not start it for a few weeks, > > I do not want to have to deal with potentially thousands of messages > > that might be waiting to be processed because there does not seem to > > be a way to opt out of all subscriptions. I know this is a feature of > > ESB, but for desktop applications, I do not want it (there's the > > feeling that I am trying to use ESB for the wrong reasons, again). > > You could modify the subscription storage to require a heartbeat, if you > don't get a heartbeat after X amount of time, it will unsubscribe the > endpoint. > > > 3. In almost all of the cases where my code handles a response or an > > event from the server, the main work is to update the UI, which must > > be performed on the main thread. I know that I can write a consumer > > that will raise an event with an event aggregator, but for most cases > > that is additional code that does not buy me much. I would like to be > > able to force individual consumers to be marshalled on the UI thread, > > but as far as I can see that means implementing my own IReflection > > interface, and that interface does *way* more than invoke the Consume > > method, and it is not all that pluggable. I am guessing that if > > something like this is not all that easy yet, perhaps I am trying to > > do something that nobody else wants to do? > > That is actually pretty complex, mostly because it might break transactional > guarantees. > I suppose we can do syncronous invoke, but I am not sure that I like it very > much. > Have you seen how this is handled in Alexandria code? > > > I'd really appreciate some pointers from people who have tried this > > sort of thing in production environments. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Rhino Tools Dev" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<rhino-tools-dev%[email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/rhino-tools-dev?hl=en. -- You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.
