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.
