[nservicebus] Re: Multiple endpoints in a single host process
pawel.pabich
Hi Guys,
Just curious if the CI packages have any bits I start playing with ?
Thanks
Pawel
--- In nserv...@yahoogroups.com, Jonathan Matheus <jmatheus@...> wrote:
>
> We just started working on this functionality and it should be in the CI Nuget package very soon.
>
> Jonathan
>
>
>
> On May 27, 2012, at 9:05 AM, "pawel.pabich" <pawel@...> wrote:
>
> > Bump. I can't imagine nobody has tried this before.
> >
> > Thanks
> >
> > Pawel
> >
> > --- In nserv...@yahoogroups.com, "pawel.pabich" <pawel@> wrote:
> > >
> > > Hi,
> > >
> > > I host subscribers and the publisher in the same process. The process is deployed on 2 boxes so all messages are routed via a single instance of a distributor.
> > >
> > > A side effect of this setup is that from the publisher perspective there is only one subscriber so it publishes only one message and then all subscribers are executed within the same transaction. This makes them implicitly dependent on each other and extends the duration of the transaction. The only solution to this problem I can see is to make sure the subscribers are hosted in different endpoints which is what Udi recommends anyway :).
> > >
> > > My project is in what would call "startup mode" so our main concerns are:
> > > - velocity
> > > - correctness
> > >
> > > This means I'm looking for something that is F5 friendly as we have to be able to run the whole system on every dev machine to be able to debug problems quickly.
> > >
> > > I read somewhere, I can't find it right now, that there was some effort put into a host that can run multiple endpoints. Is this still on the list of features to implement? If not then I will have to do it myself but I don't want to start from scratch so I would appreciate any guidelines, links, existing proofs of concept.
> > >
> > > Thanks
> > >
> > > Pawel
> > >
> >
> >
>
| Reply via web post | Reply to sender | Reply to group | Start a New Topic | Messages in this topic (6) |
Jonathan Matheus
kijana.woodard
Hi Jonathan. Thanks for that. I was getting a little heartburn about this feature. It seems like it could cause more problems than it solves. Off the top of my head, would we now have to configure which host a handler is for? One of the great SOA friendly features of NSB is the ability to drop an assembly into a bin folder with a host and have it get picked up and executed.
What is the problem with having two endpoints in a solution and using multiple start projects, like the samples, for the "clone and F5" experience?
BTW, multiple start projects blew my mind the first time I ran an NSB sample since I had never seen that before. Maybe I'm easily impressed, but it's quite effective.
kijana.woodard
That would be too much logical coupling for my taste and would require a non obvious folder structure to keep r# from complaining.
--- In nserv...@yahoogroups.com, "Jeremy Lew" <jeremy@...> wrote:
>
> I would vote for a default convention-based approach which would work at the namespace level (something like: all handlers with a namespace ending in "MyEndpoint" would be loaded by MyEndpoint.) You could still drop a new assembly in there, as long as the classes obey the conventions. The convention would be pluggable, of course ;)
Jonathan Matheus
Jeremy Lew
I would vote for a default convention-based approach which would work at the namespace level (something like: all handlers with a namespace ending in "MyEndpoint" would be loaded by MyEndpoint.) You could still drop a new assembly in there, as long as the classes obey the conventions. The convention would be pluggable, of course ;)
--- In nserv...@yahoogroups.com, "kijana.woodard" <nservicebus@...> wrote:
>
> Hi Jonathan. Thanks for that. I was getting a little heartburn about this feature. It seems like it could cause more problems than it solves. Off the top of my head, would we now have to configure which host a handler is for? One of the great SOA friendly features of NSB is the ability to drop an assembly into a bin folder with a host and have it get picked up and executed.
>
> What is the problem with having two endpoints in a solution and using multiple start projects, like the samples, for the "clone and F5" experience?
>
> BTW, multiple start projects blew my mind the first time I ran an NSB sample since I had never seen that before. Maybe I'm easily impressed, but it's quite effective.
>
Ramon Smits
It seems like it could cause more problems than it solves. Off the top of my head, would we now have to configure which host a handler is for?
There are lost of cases where you group multiple AC's into a single package. Think of a composite web app. This isn't logical coupling. Logical coupling has to do with ownership, not where your code source resides or how you choose to package it for deployment. I agree with the convention approach. However, this will be pluggable and the convention approach will probably not be the default.
Jeremy Lew
+1 to this and Jonathan, these are exactly my motivations, particularly the development box F5 and resource usage concerns. I would go a step further and actually not require an AppDomain per endpoint. I'm not sure if my NSB architecture is typical, but I have about 7 services which are the result of breaking out parts of a formerly-monolithic application. Each endpoint does work in one of these categories:
1. Scheduled maintenance/processing jobs
2. Handling of domain events to do eventually-consistent things like full text indexing and provisioning of external systems
3. Handling of long-running processing tasks that require chunking of work in order to stay within transaction timeouts
I think I have decent logical separation, but in fact all of my endpoints end up injecting the same core infrastructure code and talking to the same set of databases (some of them talk to external systems as well.) I have already written my own host (for development boxes) that does the endpoint-per-appdomain thing and it works quite well. However, it still takes at least half a gig of RAM per AppDomain. If I could allocate threads within a single AppDomain to multiple endpoints, I would be a lot better off from the resource usage perspective.
rosieks2
Will "MultiendpointHost" support restart endpoint after config change (similar like do it IIS) and/or provide some interface to start/stop endpoints?
--- In nserv...@yahoogroups.com, "Udi Dahan" <thesoftwaresimplist@...> wrote:
>
> Yes - this is still on our roadmap.
>
>
>
> Udi
>
>
>
>
>
> From: nserv...@yahoogroups.com [mailto:nserv...@yahoogroups.com] On
> Behalf Of pawel.pabich
> Sent: Sunday, May 27, 2012 5:05 PM
> To: nserv...@yahoogroups.com
> Subject: [nservicebus] Re: Multiple endpoints in a single host process
>
>
>
>
>
> Bump. I can't imagine nobody has tried this before.
>
> Thanks
>
> Pawel
>
> --- In nserv...@yahoogroups.com <mailto:nservicebus%40yahoogroups.com> ,
> _____
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2176 / Virus Database: 2425/5025 - Release Date: 05/27/12
>
Ramon Smits
+1 to this and Jonathan, these are exactly my motivations, particularly the development box F5 and resource usage concerns. I would go a step further and actually not require an AppDomain per endpoint. I'm not sure if my NSB architecture is typical, but I have about 7 services which are the result of breaking out parts of a formerly-monolithic application. Each endpoint does work in one of these categories:
I think I have decent logical separation, but in fact all of my endpoints end up injecting the same core infrastructure code and talking to the same set of databases (some of them talk to external systems as well.)
I have already written my own host (for development boxes) that does the endpoint-per-appdomain thing and it works quite well. However, it still takes at least half a gig of RAM per AppDomain. If I could allocate threads within a single AppDomain to multiple endpoints, I would be a lot better off from the resource usage perspective.
kijana.woodard
My comment about logical coupling was in reference to the suggestion of using a namespace convention to identify the endpoint to run under. One of the selling points I use for operations staff is that, by using messaging and NServiceBus, _they_ get more control. They can see that an endpoint will violate an SLA and make changes to the deployment of the system accordingly. If namespace is used to determine the endpoint, we're back to a state of nature - Find a developer, Stop the developer from doing whatever they are doing (sleeping?), Change code, Build, Check in, CI Build, Run Tests, Skip Manual QA?????, then deploy where you want to.
The convention that exists today is that a handler in the bin folder gets invoked if an appropriate message arrives. That convention seems perfectly valid and allows the operations person to skip right to the last step - redeploy.
With regard to starting "a bunch of endpoints", I've used powershell to great effect here. Commenting out endpoints I don't care about gives fine grained control without monkeying with the source project. Generally, I've only got 1-3 endpoints running anyway. Start up a client, Send a command, Server processes and Publishes, subscriber processes Event. Check in. Continue testing in another environment (dev integration, qa, whatever). I can't imagine trying to make sense of 50 console windows.
In terms of operational overhead, with my current client, we've pushed conventions quite far so that simply adding a new endpoint (or website fwiw) to the git repo results in it being built and offered as a deployment option, automatically. We could push this further, but atm, we have all the deployment configuration and environment specific configuration in a separate git repo that anyone (dev/qa/ops) can modify and check in. We're getting to the point with powershell scripts where even the operations folks don't need to log into the prod environment. Operational overhead is quite light.
500MB of RAM each? My endpoints tend to run around 10% of that. Small enough that I've never really considered that memory usage before right now.
Yes, websites, like NServiceBus.host.exe are bits of code owned by the IT/OPS service and provide a harness for the other services to run within. That, in itself, is not coupling. However, an approach like FubuMVC's "Bottles" would seem to lead to much stronger decoupling since it's quite clear that you are "bringing in" functionality from "somewhere else". At the moment, it's tricky to explain that "the website" is not a service; that we can have many websites and many endpoints and in any of those, one to many other services could be running code.
I'm afraid that people will build massive monolithic projects and ReSharper will, oh so easily, allow people to violate SOA boundaries.
All that said, I have a lot of faith in the NServiceBus core team and I doubt that they would provide a solution that would deteriorate the idioms that they themselves have established. I look forward to seeing what they come up with. I also confess that I am not familiar with TopShelf shelving and how that might make the configuration story make sense.
--- In nserv...@yahoogroups.com, Ramon Smits <ramon.smits@...> wrote:
>
Jeremy Rosenberg
Actually topshelf doesn't support shelving anymore.
alexey_zimarev
I can give you my example. I have two endpoints locally where one is communicating with Azure endpoint and the other one communicates to local endpoints. So it is a sort of dispatcher. But now it is very complex to transfer messages between these endpoints.
--- In nserv...@yahoogroups.com, "kijana.woodard" <nservicebus@...> wrote:
>
> Hi Jonathan. Thanks for that. I was getting a little heartburn about this feature. It seems like it could cause more problems than it solves. Off the top of my head, would we now have to configure which host a handler is for? One of the great SOA friendly features of NSB is the ability to drop an assembly into a bin folder with a host and have it get picked up and executed.
>
> What is the problem with having two endpoints in a solution and using multiple start projects, like the samples, for the "clone and F5" experience?
>
> BTW, multiple start projects blew my mind the first time I ran an NSB sample since I had never seen that before. Maybe I'm easily impressed, but it's quite effective.
>
kijana.woodard
This is a bridge.
I'm not sure what your Azure endpoint looks like (never played with Azure), but could you set up an NSB Satellite to deal with that? I did something like this with TIBCO. Net effect was if you Bus.Publish from a NSB, the event is pushed onto both MSMQ and Tibco. Bus.Send would be the same, except it might only go out to TIBCO. Receiving Events and Commands from TIBCO are translated, as quickly as possible, back into the NServiceBus idioms and dealt with normally.
I'm also not sure what having them both in one endpoint truly buys you in terms of the "complexity". You'd have to go into your domain, but are you talking about "republishing" Events or something? You'd still have to do work to get the messages to "hop" queue techs. If the "hop" was handled by NSB, it wouldn't really matter if it were 1 or 2 endpoints, from that pov.
--- In nserv...@yahoogroups.com, "alexey_zimarev" <azimarev@...> wrote:
>
> I can give you my example. I have two endpoints locally where one is communicating with Azure endpoint and the other one communicates to local endpoints. So it is a sort of dispatcher. But now it is very complex to transfer messages between these endpoints.
>
Udi Dahan
The place to implement this kind of transport bridging is the gateway – no need for separate hosting.
Cheers,
Udi
From: nserv...@yahoogroups.com [mailto:nserv...@yahoogroups.com] On Behalf Of kijana.woodard
Sent: Friday, November 02, 2012 2:09 AM
To: nserv...@yahoogroups.com
Subject: [nservicebus] Re: Multiple endpoints in a single host process
This is a bridge.
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2741 / Virus Database: 2614/5844 - Release Date: 10/20/12
Internal Virus Database is out of date.
alexey_zimarev
Gateway goes over HTTP, I don't need HTTP. I must receive messages from Azure AppFabric Queue, do some transformations and forward it via MSMQ. Gateway is not capable to do this as far as I understand.
Andreas Öhlund
That is correct, you need to implement a https://github.com/NServiceBus/NServiceBus/blob/master/src/gateway/NServiceBus.Gateway/Channels/IChannelReceiver.cs for the Azure AppFabric Queues and plug it into the gateway if you want to go down that route.
Gateway goes over HTTP, I don't need HTTP. I must receive messages from Azure AppFabric Queue, do some transformations and forward it via MSMQ. Gateway is not capable to do this as far as I understand.
Alexey Zimarev
I checked the interfaces already, however the gateway only resends messages, I need some data massage in between. Also Yves has done terrific job to implement Azure queue transport for the regular messaging and the best for me would be to have one host with two endpoints working as a smart gateway. I actually would like to have all endpoint capabilities at this hub point.
That is correct, you need to implement a https://github.com/NServiceBus/NServiceBus/blob/master/src/gateway/NServiceBus.Gateway/Channels/IChannelReceiver.cs for the Azure AppFabric Queues and plug it into the gateway if you want to go down that route.
Cheers,AndreasOn Mon, Nov 5, 2012 at 10:09 AM, alexey_zimarev <azim...@gmail.com> wrote:
Gateway goes over HTTP, I don't need HTTP. I must receive messages from Azure AppFabric Queue, do some transformations and forward it via MSMQ. Gateway is not capable to do this as far as I understand.
--
http://andreasohlund.net
http://twitter.com/andreasohlund
alexey_zimarev
Doesn't seem too nice though... I want to use NSB "magic" to have message handler interfaces on the forwarding endpoint, which do data conversions/transformations and send it further using Bus.Send or whatever over another transport type. If I go to implement a transport for the gateway I must do everything manually, what do I gain?
--- In nserv...@yahoogroups.com, Andreas Öhlund <andreasohlund2@...> wrote:
>
> >I checked the interfaces already, however the gateway only resends
> messages, I need some data massage in between.
> Can't you do this massage in your IChannelReceiver implementation?
>
>
> On Mon, Nov 5, 2012 at 10:23 AM, Alexey Zimarev <azimarev@...> wrote:
>
> > **
> >
> >
> > I checked the interfaces already, however the gateway only resends
> > messages, I need some data massage in between. Also Yves has done terrific
> > job to implement Azure queue transport for the regular messaging and the
> > best for me would be to have one host with two endpoints working as a smart
> > gateway. I actually would like to have all endpoint capabilities at this
> > hub point.
> >
> >
> > On Mon, Nov 5, 2012 at 10:20 AM, Andreas Öhlund <andreasohlund2@...>wrote:
> >
> >> **
> >>
> >>
> >> That is correct, you need to implement a
> >> https://github.com/NServiceBus/NServiceBus/blob/master/src/gateway/NServiceBus.Gateway/Channels/IChannelReceiver.cs for
> >> the Azure AppFabric Queues and plug it into the gateway if you want to go
> >> down that route.
> >>
> >> Cheers,
> >>
> >> Andreas
> >>
> >>
> >>
> >> On Mon, Nov 5, 2012 at 10:09 AM, alexey_zimarev <azimarev@...>wrote:
> >>
> >>> **
> >>>
> >>>
> >>> Gateway goes over HTTP, I don't need HTTP. I must receive messages from
> >>> Azure AppFabric Queue, do some transformations and forward it via MSMQ.
> >>> Gateway is not capable to do this as far as I understand.
> >>>
> >>>
> >>
> >>
> >> --
> >> http://andreasohlund.net
> >> http://twitter.com/andreasohlund
> >>
> >>
> >
> >
>
>
>
> --
> http://andreasohlund.net
> http://twitter.com/andreasohlund
>
Andreas Öhlund
Yes but to get that the sending side has to send the messages on in a format that NSB understands and in that case there isn't any need for any dataconversion/transformation?
Andreas Öhlund
>I checked the interfaces already, however the gateway only resends messages, I need some data massage in between.
I checked the interfaces already, however the gateway only resends messages, I need some data massage in between. Also Yves has done terrific job to implement Azure queue transport for the regular messaging and the best for me would be to have one host with two endpoints working as a smart gateway. I actually would like to have all endpoint capabilities at this hub point.
On Mon, Nov 5, 2012 at 10:20 AM, Andreas Öhlund <andreas...@gmail.com> wrote:
That is correct, you need to implement a https://github.com/NServiceBus/NServiceBus/blob/master/src/gateway/NServiceBus.Gateway/Channels/IChannelReceiver.cs for the Azure AppFabric Queues and plug it into the gateway if you want to go down that route.
Cheers,AndreasOn Mon, Nov 5, 2012 at 10:09 AM, alexey_zimarev <azim...@gmail.com> wrote:
Gateway goes over HTTP, I don't need HTTP. I must receive messages from Azure AppFabric Queue, do some transformations and forward it via MSMQ. Gateway is not capable to do this as far as I understand.
http://andreasohlund.net
http://twitter.com/andreasohlund
alexey_zimarev
My scenario requires Azure transport for the outer message where inner message is encrypted in the outer message payload. Local NSB host should receive this outer message from Azure queue and decrypt it (this works OK) and forward it to another local NSB host that handles the inner message. The second hop is using MSMQ transport. It is indeed possible to use MSMQ transport alongside with the Azure transport, it actually happens when I configure my local endpoint as As_Server with timeout manager enabled, it tries to initialise an error queue with MSMQ. However timeout manager initializes its transport completely in the code. I don't want this, I just want to follow the same paradigm as we use for all standard endpoints, basically I want one host to serve two endpoints and some way these endpoints to communicate with each other, that's all, not very complex.
--- In nserv...@yahoogroups.com, "kijana.woodard" <nservicebus@...> wrote:
>
> This is a bridge.
>
> I'm not sure what your Azure endpoint looks like (never played with Azure), but could you set up an NSB Satellite to deal with that? I did something like this with TIBCO. Net effect was if you Bus.Publish from a NSB, the event is pushed onto both MSMQ and Tibco. Bus.Send would be the same, except it might only go out to TIBCO. Receiving Events and Commands from TIBCO are translated, as quickly as possible, back into the NServiceBus idioms and dealt with normally.
>
> I'm also not sure what having them both in one endpoint truly buys you in terms of the "complexity". You'd have to go into your domain, but are you talking about "republishing" Events or something? You'd still have to do work to get the messages to "hop" queue techs. If the "hop" was handled by NSB, it wouldn't really matter if it were 1 or 2 endpoints, from that pov.
>
alexey_zimarev
Well, I have described just a small part of my solution requirements. In fact, the on-premises host receives one type of message, where the actual message is encrypted in its payload, so the local host should receive it from Azure AppFabric queue, decrypt it and send it via MSMQ to a locally located handler, which is another NSB host. As far as I learned from gateway documentation, this scenario is not something I can easily achieve out of the box.
--- In nserv...@yahoogroups.com, "Udi Dahan" <thesoftwaresimplist@...> wrote:
>
> The place to implement this kind of transport bridging is the gateway - no
> need for separate hosting.
>
> Cheers,
>
> Udi
>
> From: nserv...@yahoogroups.com [mailto:nserv...@yahoogroups.com] On
> Behalf Of kijana.woodard
> Sent: Friday, November 02, 2012 2:09 AM
> To: nserv...@yahoogroups.com
> Subject: [nservicebus] Re: Multiple endpoints in a single host process
>
>
>
>
>
> This is a bridge.
>
> I'm not sure what your Azure endpoint looks like (never played with Azure),
> but could you set up an NSB Satellite to deal with that? I did something
> like this with TIBCO. Net effect was if you Bus.Publish from a NSB, the
> event is pushed onto both MSMQ and Tibco. Bus.Send would be the same, except
> it might only go out to TIBCO. Receiving Events and Commands from TIBCO are
> translated, as quickly as possible, back into the NServiceBus idioms and
> dealt with normally.
>
> I'm also not sure what having them both in one endpoint truly buys you in
> terms of the "complexity". You'd have to go into your domain, but are you
> talking about "republishing" Events or something? You'd still have to do
> work to get the messages to "hop" queue techs. If the "hop" was handled by
> NSB, it wouldn't really matter if it were 1 or 2 endpoints, from that pov.
>
> --- In nserv...@yahoogroups.com <mailto:nservicebus%40yahoogroups.com> ,
> "alexey_zimarev" <azimarev@> wrote:
> >
> > I can give you my example. I have two endpoints locally where one is
> communicating with Azure endpoint and the other one communicates to local
> endpoints. So it is a sort of dispatcher. But now it is very complex to
> transfer messages between these endpoints.
> >
> > --- In nserv...@yahoogroups.com <mailto:nservicebus%40yahoogroups.com>
> , "kijana.woodard" <nservicebus@> wrote:
> > >
> > > Hi Jonathan. Thanks for that. I was getting a little heartburn about
> this feature. It seems like it could cause more problems than it solves. Off
> the top of my head, would we now have to configure which host a handler is
> for? One of the great SOA friendly features of NSB is the ability to drop an
> assembly into a bin folder with a host and have it get picked up and
> executed.
> > >
> > > What is the problem with having two endpoints in a solution and using
> multiple start projects, like the samples, for the "clone and F5"
> experience?
> > >
> > > BTW, multiple start projects blew my mind the first time I ran an NSB
> sample since I had never seen that before. Maybe I'm easily impressed, but
> it's quite effective.
> > >
> > > --- In nserv...@yahoogroups.com
> <mailto:nservicebus%40yahoogroups.com> , Jonathan Matheus <jmatheus@> wrote:
> > > >
> > > > Pawel,
> > > > Not yet, we have since changed direction in how we plan to implement
> the multihost. I'll post to the user group as soon as there's a spike
> available for testing, so we can get as much feedback as possible.
> > > >
> > > > Thanks,
> > > > Jonathan Matheus
> > > >
> > > >
> > > >
> > > > On Oct 22, 2012, at 6:01 AM, "pawel.pabich" <pawel@> wrote:
> > > >
> > > > > Hi Guys,
> > > > >
> > > > > Just curious if the CI packages have any bits I start playing with ?
> > > > >
> > > > > Thanks
> > > > >
> > > > > Pawel
> > > > >
> > > > > --- In nserv...@yahoogroups.com
> <mailto:nservicebus%40yahoogroups.com> , Jonathan Matheus <jmatheus@> wrote:
> > > > > >
> > > > > > We just started working on this functionality and it should be in
> the CI Nuget package very soon.
> > > > > >
> > > > > > Jonathan
> > > > > >
> > > > > >
> > > > > >
> > > > > > On May 27, 2012, at 9:05 AM, "pawel.pabich" <pawel@> wrote:
> > > > > >
> > > > > > > Bump. I can't imagine nobody has tried this before.
> > > > > > >
> > > > > > > Thanks
> > > > > > >
> > > > > > > Pawel
> > > > > > >
> > > > > > > --- In nserv...@yahoogroups.com
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2013.0.2741 / Virus Database: 2614/5844 - Release Date: 10/20/12
> Internal Virus Database is out of date.
>
ekfarr
Will this support be in 4.0?
Thanks,
Eric
--- In nserv...@yahoogroups.com, "Udi Dahan" <thesoftwaresimplist@...> wrote:
>
> Yes - this is still on our roadmap.
>
>
>
> Udi
>
>
>
>
>
> From: nserv...@yahoogroups.com [mailto:nserv...@yahoogroups.com] On
> Behalf Of pawel.pabich
> Sent: Sunday, May 27, 2012 5:05 PM
> To: nserv...@yahoogroups.com
> Subject: [nservicebus] Re: Multiple endpoints in a single host process
>
>
>
>
>
> Version: 2012.0.2176 / Virus Database: 2425/5025 - Release Date: 05/27/12
>
)&t=J_3-D_3&al=(as$121cs9abe,aid$GkTwIGKL4Gk-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$1214ubf0k,aid$4JnwIGKL4Gk-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121das413,aid$pu_wIGKL4Gk-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
John Simons
)&t=J_3-D_3&al=(as$121ql425d,aid$sdCpEWKL4Mw-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121bg1hni,aid$fP2pEWKL4Mw-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121idqmrq,aid$RyqqEWKL4Mw-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
Udi Dahan
I’m afraid that we weren’t able to dedicate enough time to work on this feature and it ended up sliding out of the 4.0 release which, quite frankly, was delayed long enough already.
We haven’t given up on it but other things always end up taking precedence.
With thanks,
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3162/6284 - Release Date: 04/29/13
)&t=J_3-D_3&al=(as$12193ht73,aid$gH5WCGKLF.A-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121lmptq5,aid$7olWCGKLF.A-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121aom9n9,aid$XJVWCGKLF.A-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
timpduncan
Udi,
IIRC, this was originally going to be implemented using TopShelf and it's shelving concept. Is this still the case or is there some other method that is being investigated?
What about IIS-hosted or perhaps some other app container (if there are any)?
Regards,
Tim.
--- In nserv...@yahoogroups.com, "Udi Dahan" <thesoftwaresimplist@...> wrote:
>
> I'm afraid that we weren't able to dedicate enough time to work on this
> feature and it ended up sliding out of the 4.0 release which, quite frankly,
> was delayed long enough already.
>
>
>
> We haven't given up on it but other things always end up taking precedence.
>
>
>
> With thanks,
>
>
>
> Udi
>
>
>
>
>
> From: nserv...@yahoogroups.com [mailto:nserv...@yahoogroups.com] On
> Behalf Of John Simons
> Sent: Thursday, May 02, 2013 2:29 AM
> To: nserv...@yahoogroups.com
> Subject: Re: [nservicebus] Re: Multiple endpoints in a single host process
>
>
>
>
>
> No
>
>
>
> On 2 May 2013 00:22, ekfarr <eric@...> wrote:
>
>
>
> Will this support be in 4.0?
>
> Thanks,
> Eric
>
>
>
> --- In nserv...@yahoogroups.com <mailto:nservicebus%40yahoogroups.com> ,
> "Udi Dahan" <thesoftwaresimplist@> wrote:
> >
>
> > Yes - this is still on our roadmap.
> >
> >
> >
>
> > Udi
> >
> >
> >
> >
> >
> > From: nserv...@yahoogroups.com <mailto:nservicebus%40yahoogroups.com>
> [mailto:nserv...@yahoogroups.com <mailto:nservicebus%40yahoogroups.com> ]
> On
>
> > Behalf Of pawel.pabich
> > Sent: Sunday, May 27, 2012 5:05 PM
>
> > To: nserv...@yahoogroups.com <mailto:nservicebus%40yahoogroups.com>
> > Subject: [nservicebus] Re: Multiple endpoints in a single host process
> >
> >
> >
> >
> >
>
> > Bump. I can't imagine nobody has tried this before.
> >
> > Thanks
> >
> > Pawel
> >
>
> > --- In nserv...@yahoogroups.com <mailto:nservicebus%40yahoogroups.com>
> <mailto:nservicebus%40yahoogroups.com
> <mailto:nservicebus%2540yahoogroups.com> > ,
> Version: 2013.0.2904 / Virus Database: 3162/6284 - Release Date: 04/29/13
>
)&t=J_3-D_3&al=(as$121sahg2t,aid$5sQMJWKL4N0-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121m6dcig,aid$_CcNJWKL4N0-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121od20ua,aid$EosNJWKL4N0-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
kijana.woodard
IIRC, the topshelf team removed multiple services support in 3.0.
http://stackoverflow.com/a/9227188/214073
I guess I'm a Luddite on this issue, but what's the win again?
It seems, conceptually, to add a lot of complexity for very little value.
Where is the order process running?
Oh on machine XYZ it's running as Generic Host 5 with 7 other unrelated things.
Hey I just started this endpoint and it created 19 input queues, what gives?
Oh yeah, I combined a bunch of services into one host to make things easier.
I figure there's some value because it keeps coming up.
What am I missing?
--- In nserv...@yahoogroups.com, "timpduncan" <tim.duncan@...> wrote:
>
> Udi,
>
> IIRC, this was originally going to be implemented using TopShelf and it's shelving concept. Is this still the case or is there some other method that is being investigated?
>
> What about IIS-hosted or perhaps some other app container (if there are any)?
>
> Regards,
> Tim.
>
)&t=J_3-D_3&al=(as$121v13hnd,aid$00HdCmKL4hM-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$1219ah15c,aid$YIndCmKL4hM-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121ebuq0s,aid$7dDdCmKL4hM-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
John Simons
)&t=J_3-D_3&al=(as$121qplb5b,aid$d.VJG2KL4HQ-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121l7q149,aid$4vlJG2KL4HQ-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$12117jbgk,aid$TQ5KG2KL4HQ-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
timpduncan
I'm not sure that conceptually there is much difference in complexity.
(IIS seems to be able to handle multiple web sites and applications without too much confusion to most people.)
But I agree that in production you probably don't gain much in terms of benefit. Maybe deployment could be easier using something akin to IIS-hosted endpoints. Or perhaps an easier grouping/view of an application for Ops?
Where I think it might be more helpful is in the "F5" style of development and debugging. Making it easy to deploy, host and debug all of your endpoints without all those console windows would be nice.
--- In nserv...@yahoogroups.com, "kijana.woodard" <nservicebus@...> wrote:
>
)&t=J_3-D_3&al=(as$121li62fi,aid$BJ.dLGKL4HY-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121h7j5g3,aid$wNudLGKL4HY-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121n9972a,aid$fBieLGKL4HY-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
timpduncan
FWIW, and in case this saves someone from extra work, the TopShelf guys have not ruled out shelving making a comeback...
https://groups.google.com/d/msg/topshelf-discuss/VtNJQcSCilU/dm0VW
--- In nserv...@yahoogroups.com, John Simons <john.simons@...> wrote:
>
> Hi Tim,
>
> We looked at using the shelves in Topshelf but unfortunately was not very
> stable and actually since then the Topshelf team has dropped that feature.
> So the plan forward is to probably drop TS and just do some good old
> fashion AppDomain voodoo ourselves :)
>
> Cheers
> John
>
>
>
> On 3 May 2013 09:34, timpduncan <tim.duncan@...> wrote:
>
> > **
> >
> >
> > Udi,
> >
> > IIRC, this was originally going to be implemented using TopShelf and it's
> > shelving concept. Is this still the case or is there some other method that
> > is being investigated?
> >
> > What about IIS-hosted or perhaps some other app container (if there are
> > any)?
> >
> > Regards,
> > Tim.
> >
> >
> > --- In nserv...@yahoogroups.com, "Udi Dahan" <thesoftwaresimplist@>
)&t=J_3-D_3&al=(as$121jkbes5,aid$Ef3WKWKL4Ns-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$1213c4sts,aid$QnvXKWKL4Ns-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121cjbuas,aid$c_nXKWKL4Ns-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
Jeremy Rosenberg
)&t=J_3-D_3&al=(as$121dknquq,aid$1DgsgGKL4hM-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121el8md8,aid$7qosgGKL4hM-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$12107kckk,aid$CB0tgGKL4hM-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
kijana.woodard
Maybe my approach to dev with nsb is just ... strange.
In my mind, I switch gears radically moving from one endpoint to another, as if I am "another team" working on this other endpoint. From that pov, having a bunch of endpoints up doesn't quite compute.
Sometimes I like to have two or three consoles up for the "blinking light" effect. For the most part through, I get one endpoint working. Then I get a second one working. Then when I start on the third, the first one either doesn't get turned on at all or gets installed as a service. If I want confirmation that its "doing something", I tail the log file.
The beauty of this approach to architecture is that once an endpoint is handling it's command/event, I can pretty much forget about it assume it's working until I see something popping into the error queue. Every now and then I think, "hey is that thing on" and low and behold it's just been there doing it's thing.
My favorite is when I've had several endpoints off for days, and the rest of the app I've been working on has been functioning anyway. Then I remember and turn on those endpoints and they zip through the standing messages. That always makes me smile. :-D
And if I want to start/stop a bunch at once: powershell.
Maybe something like this could help: http://www.winsplit-revolution.com/
But what I'd really like, in general, is 3 or 4 monitors instead of 2. I've seen programmers and traders with 4+ and it really looks....nice. ;-)
--- In nserv...@yahoogroups.com, Jeremy Rosenberg <jdr@...> wrote:
>
> Agree. For us it would be development, assuming the host is intuitive
> enough. Even if not tho, I think it beats all of those blasted console
> windows..
>
> Also I know some people have been talking about high memory usage recently.
> There's a possibility here to reduce that. I'm no expert in domain
> neutral assemblies, but I do believe most of the assemblies could be jitted
> once and shared with all domains at a small runtime performance hit. I
> would think that would help startup times of all endpoints after the first
> as well, which I know developers wouldn't complain about ;)
>
> Meh.. may not know what it actually means from all angles until it happens
> and people use it in different scenarios. Point is (at least for me) it's
> not about changing the architectural principles behind it. It's about
> making building and managing it simpler - and MAYBE deploying. Just
> changing the boundary from process to app domain. Tradeoff is that while
> the OS manages process isolation for you, app domains not so much :)
>
> I know Jeremy Lew was saying he's already doing this in development. And I
> know it's crossed my mind as well.
>
> Once this is done, next up is NServiceBus OS. Instead of a silly
> synchronous keyboard and mouse, you interact with it via e-mail.
>
>
> On Fri, May 3, 2013 at 12:34 AM, timpduncan <tim.duncan@...>wrote:
>
> > **
> >
> >
> > I'm not sure that conceptually there is much difference in complexity.
> > (IIS seems to be able to handle multiple web sites and applications
> > without too much confusion to most people.)
> >
> > But I agree that in production you probably don't gain much in terms of
> > benefit. Maybe deployment could be easier using something akin to
> > IIS-hosted endpoints. Or perhaps an easier grouping/view of an application
> > for Ops?
> >
> > Where I think it might be more helpful is in the "F5" style of development
> > and debugging. Making it easy to deploy, host and debug all of your
> > endpoints without all those console windows would be nice.
> >
> >
> > --- In nserv...@yahoogroups.com, "kijana.woodard" <nservicebus@>
)&t=J_3-D_3&al=(as$121sqhs7q,aid$NoM.BGKL4Mg-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121m0gvcc,aid$KJI.BGKL4Mg-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121hisa8k,aid$GqE.BGKL4Mg-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
jerdrosenberg
I have 3 monitors here - two 27s and a vertical 24. But it's never enough for us spoiled developer folk, is it!? :D hehehe
Anyway, I see what you mean. I'm not saying that approach is wrong since it obviously is working well for you, but it's certainly different from what I've experienced so far. I imagine we're using send more while you are in general publishing. So an end-to-end is much more explicit from the start. And generally features implemented one at a time cut through multiple endpoints, so you end up going back and forth (we have). Debugging/installing/uninstalling/repeat is not really an option in these scenarios.
Re: mass starting services, managing windows, etc. yeah there are tools for doing similar things. My point is managing this has been brought up a # of times by a # of different people, and each team has to keep developing or gathering similar tooling to manage it. That kind of cross cutting stuff would IMO make an attractive addition to the product.
Even if it's just psychological, starting out with this one of the big thoughts on my mind was "am I really going to be able to push this? No one is going to want to run all of these console windows!" That's a silly thing to have nightmares about when there is so much more to worry about when freshly bringing on this infrastructure to an organization. I'm sure I'm not the only one. So even if it doesn't have production value.. as a business, it seems worthwhile to make one less reason to make n00bs (like me) avoid the product, especially if it's a silly reason :)
Of course it only makes sense if it doesn't make the product worse hehe. And clearly more research has to be done to determine that risk.
--- In nserv...@yahoogroups.com, "kijana.woodard" <nservicebus@...> wrote:
>
> Maybe my approach to dev with nsb is just ... strange.
>
> In my mind, I switch gears radically moving from one endpoint to another, as if I am "another team" working on this other endpoint. From that pov, having a bunch of endpoints up doesn't quite compute.
>
> Sometimes I like to have two or three consoles up for the "blinking light" effect. For the most part through, I get one endpoint working. Then I get a second one working. Then when I start on the third, the first one either doesn't get turned on at all or gets installed as a service. If I want confirmation that its "doing something", I tail the log file.
>
> The beauty of this approach to architecture is that once an endpoint is handling it's command/event, I can pretty much forget about it assume it's working until I see something popping into the error queue. Every now and then I think, "hey is that thing on" and low and behold it's just been there doing it's thing.
>
> My favorite is when I've had several endpoints off for days, and the rest of the app I've been working on has been functioning anyway. Then I remember and turn on those endpoints and they zip through the standing messages. That always makes me smile. :-D
>
> And if I want to start/stop a bunch at once: powershell.
>
> Maybe something like this could help: http://www.winsplit-revolution.com/
>
> But what I'd really like, in general, is 3 or 4 monitors instead of 2. I've seen programmers and traders with 4+ and it really looks....nice. ;-)
>
)&t=J_3-D_3&al=(as$121bets5c,aid$gVTFHWKL4G0-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121ub91hs,aid$eIPFHWKL4G0-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$1211m4171,aid$b7LFHWKL4G0-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
Jimmy Bogard
)&t=J_3-D_3&al=(as$121cfkuvc,aid$JIuaG2KL4NU-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$1215nrtdb,aid$ctaaG2KL4NU-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121cpjus8,aid$wCGbG2KL4NU-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
Jeremy Lew
It’s ridiculous to have to figure out which one of the 10 .exe processes you want to attach the debugger to in your local dev environment. Honestly, I would rather have a single AppDomain with multiple endpoints than multiple AppDomains, because each AppDomain pays the startup cost of IoC registration, Entity Framework model compilation, etc. I’m not sure how typical my application is, but all my endpoints are compiled by the same solution, use common core assemblies, etc. A single endpoint can start in a few very CPU-intensive seconds, but all 10 of them recycling simultaneously after a build take quite a while to initialize. My faux ServiceHost will restart automatically when the bin directory changes, but it still not a friction-free compile-debug cycle.
)&t=J_3-D_3&al=(as$121mop3f6,aid$Xe8eiGKL4Mk-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$1213iglje,aid$Km4fiGKL4Mk-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$1214n1lr8,aid$9.wfiGKL4Mk-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
Alexey Zimarev
My interest in having multiple endpoints in one host was always in multiple transport support per endpoint.
)&t=J_3-D_3&al=(as$121vrv6a2,aid$RgXzAGKL4Jk-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121m7ck4b,aid$bBjzAGKL4Jk-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121b3tiq0,aid$kivzAGKL4Jk-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
kijana.woodard
Satellites are good for this.
--- In nserv...@yahoogroups.com, "Alexey Zimarev" <azimarev@...> wrote:
>
> My interest in having multiple endpoints in one host was always in multiple
> transport support per endpoint.
>
>
>
> From: nserv...@yahoogroups.com [mailto:nserv...@yahoogroups.com] On
> Behalf Of Jimmy Bogard
> Sent: 03 May 2013 15:51
> To: nserv...@yahoogroups.com
> Subject: Re: [nservicebus] Re: Multiple endpoints in a single host process
>
>
>
>
>
> Testing would be nice. I wouldn't do this in production, but integration
> testing and local testing/running would be a lot easier w/o
> process-per-endpoint.
>
>
>
> On Thu, May 2, 2013 at 7:00 PM, kijana.woodard <nservicebus@...
> <mailto:nservicebus@...> > wrote:
>
>
>
> IIRC, the topshelf team removed multiple services support in 3.0.
> http://stackoverflow.com/a/9227188/214073
>
> I guess I'm a Luddite on this issue, but what's the win again?
>
> It seems, conceptually, to add a lot of complexity for very little value.
>
> Where is the order process running?
> Oh on machine XYZ it's running as Generic Host 5 with 7 other unrelated
> things.
>
> Hey I just started this endpoint and it created 19 input queues, what gives?
>
> Oh yeah, I combined a bunch of services into one host to make things easier.
>
> I figure there's some value because it keeps coming up.
> What am I missing?
>
>
>
> --- In nserv...@yahoogroups.com <mailto:nservicebus%40yahoogroups.com> ,
> "timpduncan" <tim.duncan@ <mailto:tim.duncan@> > wrote:
> >
> > Udi,
> >
> > IIRC, this was originally going to be implemented using TopShelf and it's
> shelving concept. Is this still the case or is there some other method that
> is being investigated?
> >
> > What about IIS-hosted or perhaps some other app container (if there are
> any)?
> >
> > Regards,
> > Tim.
> >
>
> > --- In nserv...@yahoogroups.com <mailto:nservicebus%40yahoogroups.com>
> , "Udi Dahan" <thesoftwaresimplist@> wrote:
> > >
> > > I'm afraid that we weren't able to dedicate enough time to work on this
> > > feature and it ended up sliding out of the 4.0 release which, quite
> frankly,
> > > was delayed long enough already.
> > >
> > >
> > >
> > > We haven't given up on it but other things always end up taking
> precedence.
> > >
> > >
> > >
> > > With thanks,
> > >
> > >
> > >
> > > Udi
> > >
> > >
> > >
> > >
> > >
> > > From: nserv...@yahoogroups.com <mailto:nservicebus%40yahoogroups.com>
> [mailto:nserv...@yahoogroups.com <mailto:nservicebus%40yahoogroups.com> ]
> On
> > > Behalf Of John Simons
> > > Sent: Thursday, May 02, 2013 2:29 AM
> > > To: nserv...@yahoogroups.com <mailto:nservicebus%40yahoogroups.com>
> > > Subject: Re: [nservicebus] Re: Multiple endpoints in a single host
> process
> > >
> > >
> > >
> > >
> > >
> > > No
> > >
> > >
> > >
>
> > > On 2 May 2013 00:22, ekfarr <eric@> wrote:
> > >
> > >
> > >
> > > Will this support be in 4.0?
> > >
> > > Thanks,
> > > Eric
> > >
> > >
> > >
> > > --- In nserv...@yahoogroups.com
> <mailto:nservicebus%40yahoogroups.com>
> <mailto:nservicebus%40yahoogroups.com
> <mailto:nservicebus%2540yahoogroups.com> > ,
> > > "Udi Dahan" <thesoftwaresimplist@> wrote:
> > > >
> > >
> > > > Yes - this is still on our roadmap.
> > > >
> > > >
> > > >
> > >
> > > > Udi
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > From: nserv...@yahoogroups.com
> <mailto:nservicebus%40yahoogroups.com>
> <mailto:nservicebus%40yahoogroups.com
> <mailto:nservicebus%2540yahoogroups.com> >
> > > [mailto:nserv...@yahoogroups.com
> <mailto:nservicebus%40yahoogroups.com>
> <mailto:nservicebus%40yahoogroups.com
> <mailto:nservicebus%2540yahoogroups.com> > ]
> > > On
> > >
> > > > Behalf Of pawel.pabich
> > > > Sent: Sunday, May 27, 2012 5:05 PM
> > >
> > > > To: nserv...@yahoogroups.com <mailto:nservicebus%40yahoogroups.com>
> <mailto:nservicebus%40yahoogroups.com
> <mailto:nservicebus%2540yahoogroups.com> >
> > > > Subject: [nservicebus] Re: Multiple endpoints in a single host process
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > > > Bump. I can't imagine nobody has tried this before.
> > > >
> > > > Thanks
> > > >
> > > > Pawel
> > > >
> > >
> > > > --- In nserv...@yahoogroups.com
> <mailto:nservicebus%40yahoogroups.com>
> <mailto:nservicebus%40yahoogroups.com
> <mailto:nservicebus%2540yahoogroups.com> >
> > > <mailto:nservicebus%40yahoogroups.com
> <mailto:nservicebus%2540yahoogroups.com>
> > > <mailto:nservicebus%2540yahoogroups.com
> <mailto:nservicebus%252540yahoogroups.com> > > ,
> > > > Checked by AVG - www.avg.com <http://www.avg.com>
> > >
> > > > Version: 2012.0.2176 / Virus Database: 2425/5025 - Release Date:
> 05/27/12
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > >
> > > Regards
> > >
> > > John Simons
> > >
> > > NServiceBus
> > >
> > >
> > >
> > > _____
> > >
> > > No virus found in this message.
> > > Checked by AVG - www.avg.com <http://www.avg.com>
> > > Version: 2013.0.2904 / Virus Database: 3162/6284 - Release Date:
> 04/29/13
> > >
> >
>
)&t=J_3-D_3&al=(as$121ojf4c6,aid$Z0LmBmKL4Go-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121qfejqt,aid$_FvmBmKL4Go-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$1215s0da0,aid$kXXmBmKL4Go-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
kijana.woodard
Debugger?
Ok. Just kidding.
How about making a copy of nservicebus.host.exe called {endpoint}.nservicebus.host.exe. Run that and now you know which to attach to.
Beware the shared assemblies. If you have them, they should be _stable_. Nothing worse than having to rev your entire production environment because someone made a "simple" change in a base class. SRP trumps DRY.
--- In nserv...@yahoogroups.com, Jeremy Lew <jlew@...> wrote:
>
> It's ridiculous to have to figure out which one of the 10 .exe processes you want to attach the debugger to in your local dev environment. Honestly, I would rather have a single AppDomain with multiple endpoints than multiple AppDomains, because each AppDomain pays the startup cost of IoC registration, Entity Framework model compilation, etc. I'm not sure how typical my application is, but all my endpoints are compiled by the same solution, use common core assemblies, etc. A single endpoint can start in a few very CPU-intensive seconds, but all 10 of them recycling simultaneously after a build take quite a while to initialize. My faux ServiceHost will restart automatically when the bin directory changes, but it still not a friction-free compile-debug cycle.
>
> From: nserv...@yahoogroups.com [mailto:nserv...@yahoogroups.com] On Behalf Of jerdrosenberg
> Sent: Friday, May 03, 2013 9:43 AM
> To: nserv...@yahoogroups.com
> Subject: [nservicebus] Re: Multiple endpoints in a single host process
>
>
>
> I have 3 monitors here - two 27s and a vertical 24. But it's never enough for us spoiled developer folk, is it!? :D hehehe
>
> Anyway, I see what you mean. I'm not saying that approach is wrong since it obviously is working well for you, but it's certainly different from what I've experienced so far. I imagine we're using send more while you are in general publishing. So an end-to-end is much more explicit from the start. And generally features implemented one at a time cut through multiple endpoints, so you end up going back and forth (we have). Debugging/installing/uninstalling/repeat is not really an option in these scenarios.
>
> Re: mass starting services, managing windows, etc. yeah there are tools for doing similar things. My point is managing this has been brought up a # of times by a # of different people, and each team has to keep developing or gathering similar tooling to manage it. That kind of cross cutting stuff would IMO make an attractive addition to the product.
>
> Even if it's just psychological, starting out with this one of the big thoughts on my mind was "am I really going to be able to push this? No one is going to want to run all of these console windows!" That's a silly thing to have nightmares about when there is so much more to worry about when freshly bringing on this infrastructure to an organization. I'm sure I'm not the only one. So even if it doesn't have production value.. as a business, it seems worthwhile to make one less reason to make n00bs (like me) avoid the product, especially if it's a silly reason :)
>
> Of course it only makes sense if it doesn't make the product worse hehe. And clearly more research has to be done to determine that risk.
>
> --- In nserv...@yahoogroups.com<mailto:nservicebus%40yahoogroups.com>, "kijana.woodard" <nservicebus@<mailto:nservicebus@>> wrote:
> >
> > Maybe my approach to dev with nsb is just ... strange.
> >
> > In my mind, I switch gears radically moving from one endpoint to another, as if I am "another team" working on this other endpoint. From that pov, having a bunch of endpoints up doesn't quite compute.
> >
> > Sometimes I like to have two or three consoles up for the "blinking light" effect. For the most part through, I get one endpoint working. Then I get a second one working. Then when I start on the third, the first one either doesn't get turned on at all or gets installed as a service. If I want confirmation that its "doing something", I tail the log file.
> >
> > The beauty of this approach to architecture is that once an endpoint is handling it's command/event, I can pretty much forget about it assume it's working until I see something popping into the error queue. Every now and then I think, "hey is that thing on" and low and behold it's just been there doing it's thing.
> >
> > My favorite is when I've had several endpoints off for days, and the rest of the app I've been working on has been functioning anyway. Then I remember and turn on those endpoints and they zip through the standing messages. That always makes me smile. :-D
> >
> > And if I want to start/stop a bunch at once: powershell.
> >
> > Maybe something like this could help: http://www.winsplit-revolution.com/
> >
> > But what I'd really like, in general, is 3 or 4 monitors instead of 2. I've seen programmers and traders with 4+ and it really looks....nice. ;-)
> >
> > > > --- In nserv...@yahoogroups.com<mailto:nservicebus%40yahoogroups.com>, "kijana.woodard" <nservicebus@>
> > > > wrote:
> > > > >
> > > > > IIRC, the topshelf team removed multiple services support in 3.0.
> > > > > http://stackoverflow.com/a/9227188/214073
> > > > >
> > > > > I guess I'm a Luddite on this issue, but what's the win again?
> > > > >
> > > > > It seems, conceptually, to add a lot of complexity for very little
> > > > value.
> > > > >
> > > > > Where is the order process running?
> > > > > Oh on machine XYZ it's running as Generic Host 5 with 7 other unrelated
> > > > things.
> > > > >
> > > > > Hey I just started this endpoint and it created 19 input queues, what
> > > > gives?
> > > > > Oh yeah, I combined a bunch of services into one host to make things
> > > > easier.
> > > > >
> > > > > I figure there's some value because it keeps coming up.
> > > > > What am I missing?
> > > > >
> > > > >
> > > > > --- In nserv...@yahoogroups.com<mailto:nservicebus%40yahoogroups.com>, "timpduncan" <tim.duncan@> wrote:
> > > > > >
> > > > > > Udi,
> > > > > >
> > > > > > IIRC, this was originally going to be implemented using TopShelf and
> > > > it's shelving concept. Is this still the case or is there some other method
> > > > that is being investigated?
> > > > > >
> > > > > > What about IIS-hosted or perhaps some other app container (if there
> > > > are any)?
> > > > > >
> > > > > > Regards,
> > > > > > Tim.
> > > > > >
> > > > > > --- In nserv...@yahoogroups.com<mailto:nservicebus%40yahoogroups.com>, "Udi Dahan" <thesoftwaresimplist@>
> > > > wrote:
> > > > > > >
> > > > > > > I'm afraid that we weren't able to dedicate enough time to work on
> > > > this
> > > > > > > feature and it ended up sliding out of the 4.0 release which, quite
> > > > frankly,
> > > > > > > was delayed long enough already.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > We haven't given up on it but other things always end up taking
> > > > precedence.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > With thanks,
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Udi
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > From: nserv...@yahoogroups.com<mailto:nservicebus%40yahoogroups.com> [mailto:
> > > > nserv...@yahoogroups.com<mailto:nservicebus%40yahoogroups.com>] On
> > > > > > > Behalf Of John Simons
> > > > > > > Sent: Thursday, May 02, 2013 2:29 AM
> > > > > > > To: nserv...@yahoogroups.com<mailto:nservicebus%40yahoogroups.com>
> > > > > > > Subject: Re: [nservicebus] Re: Multiple endpoints in a single host
> > > > process
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > No
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 2 May 2013 00:22, ekfarr <eric@> wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Will this support be in 4.0?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Eric
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --- In nserv...@yahoogroups.com<mailto:nservicebus%40yahoogroups.com> <mailto:
> <mailto:%0b>> > > nservicebus%40yahoogroups.com> ,
> > > > > > > "Udi Dahan" <thesoftwaresimplist@> wrote:
> > > > > > > >
> > > > > > >
> > > > > > > > Yes - this is still on our roadmap.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > > Udi
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > From: nserv...@yahoogroups.com<mailto:nservicebus%40yahoogroups.com> <mailto:
> <mailto:%0b>> > > nservicebus%40yahoogroups.com>
> > > > > > > [mailto:nserv...@yahoogroups.com<mailto:nservicebus%40yahoogroups.com> <mailto:
> > > > nservicebus%40yahoogroups.com> ]
> > > > > > > On
> > > > > > >
> > > > > > > > Behalf Of pawel.pabich
> > > > > > > > Sent: Sunday, May 27, 2012 5:05 PM
> > > > > > >
> > > > > > > > To: nserv...@yahoogroups.com<mailto:nservicebus%40yahoogroups.com> <mailto:
> <mailto:%0b>> > > nservicebus%40yahoogroups.com>
> > > > > > > > Subject: [nservicebus] Re: Multiple endpoints in a single host
> > > > process
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > > Bump. I can't imagine nobody has tried this before.
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > >
> > > > > > > > Pawel
> > > > > > > >
> > > > > > >
> > > > > > > > --- In nserv...@yahoogroups.com<mailto:nservicebus%40yahoogroups.com> <mailto:
> <mailto:%0b>> > > nservicebus%40yahoogroups.com>
> > > > > > > <mailto:nservicebus%40yahoogroups.com
> <mailto:nservicebus%40yahoogroups.com%0b>> > > > > > <mailto:nservicebus%2540yahoogroups.com> > ,
> > > > > > > > Checked by AVG - www.avg.com<http://www.avg.com>
> > > > > > >
> > > > > > > > Version: 2012.0.2176 / Virus Database: 2425/5025 - Release Date:
> > > > 05/27/12
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > >
> > > > > > > Regards
> > > > > > >
> > > > > > > John Simons
> > > > > > >
> > > > > > > NServiceBus
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _____
> > > > > > >
> > > > > > > No virus found in this message.
> > > > > > > Checked by AVG - www.avg.com<http://www.avg.com>
> > > > > > > Version: 2013.0.2904 / Virus Database: 3162/6284 - Release Date:
> > > > 04/29/13
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> >
>
)&t=J_3-D_3&al=(as$121d249m6,aid$MaIjD2KL4NI-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121bcceh5,aid$gggkD2KL4NI-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121rhc1ib,aid$024kD2KL4NI-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
Alexey Zimarev
Might be but I have not seen a single implementation of the functioning multi-transport solution.
I just heard I could use satellites or gateways but, well, is there much documentation about it? The answer is “no”.
Again, how the bus will be resolving from the container in such case? There will be no one bus.
)&t=J_3-D_3&al=(as$121cdtg45,aid$KLCFCGKL4Mg-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121er9m10,aid$y8SFCGKL4Mg-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$1217s83hq,aid$btmFCGKL4Mg-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
kijana.woodard
Now we're talking.
To some degree, I've been playing devil's advocate on this thread.
Lately I've been reading the zeromq guide. I find the idea of prototyping in a single assembly and then scaling out to multiple processes/machines without changing code to be a compelling idea. ZeroMQ doesn't have many of the _problems_ that NSB does like independent queues and polymorphic message resolution. Instead it has it's own set of problems, but that's beside the point. :-)
If there was a way that "made sense", then there might be value. Simple shoving a bunch of disparate endpoints in one host sounds like it will be more confusing in the long run.
--- In nserv...@yahoogroups.com, Jimmy Bogard <jimmy.bogard@...> wrote:
>
> Testing would be nice. I wouldn't do this in production, but integration
> testing and local testing/running would be a lot easier w/o
> process-per-endpoint.
>
>
> On Thu, May 2, 2013 at 7:00 PM, kijana.woodard <nservicebus@...>wrote:
>
> > **
)&t=J_3-D_3&al=(as$121s4j0l2,aid$UuavCGKL4HI-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121oc2la2,aid$CQKwCGKL4HI-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121h8g8ba,aid$wB2wCGKL4HI-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
kijana.woodard
https://github.com/kijanawoodard/NServiceBus.Tibco
A version of this is running in production at a former client.
--- In nserv...@yahoogroups.com, "Alexey Zimarev" <azimarev@...> wrote:
>
> Might be but I have not seen a single implementation of the functioning
> multi-transport solution.
>
>
>
> I just heard I could use satellites or gateways but, well, is there much
> documentation about it? The answer is "no".
>
>
>
> Again, how the bus will be resolving from the container in such case? There
> will be no one bus.
>
> From: nserv...@yahoogroups.com [mailto:nserv...@yahoogroups.com] On
> Behalf Of kijana.woodard
> Sent: 03 May 2013 16:50
> To: nserv...@yahoogroups.com
> Subject: [nservicebus] Re: Multiple endpoints in a single host process
>
>
>
>
>
> Satellites are good for this.
>
> --- In nserv...@yahoogroups.com <mailto:nservicebus%40yahoogroups.com> ,
> "Alexey Zimarev" <azimarev@ <mailto:azimarev@> > wrote:
> >
> > My interest in having multiple endpoints in one host was always in
> multiple
> > transport support per endpoint.
> >
> >
> >
> > From: nserv...@yahoogroups.com <mailto:nservicebus%40yahoogroups.com>
> [mailto:nserv...@yahoogroups.com <mailto:nservicebus%40yahoogroups.com> ]
> On
> > Behalf Of Jimmy Bogard
> > Sent: 03 May 2013 15:51
> > To: nserv...@yahoogroups.com <mailto:nservicebus%40yahoogroups.com>
> > Subject: Re: [nservicebus] Re: Multiple endpoints in a single host process
> >
> >
> >
> >
> >
> > Testing would be nice. I wouldn't do this in production, but integration
> > testing and local testing/running would be a lot easier w/o
> > process-per-endpoint.
> >
> >
> >
> > On Thu, May 2, 2013 at 7:00 PM, kijana.woodard <nservicebus@
> <mailto:nservicebus@%0b>
> > <mailto:nservicebus%40yahoogroups.com
> <mailto:nservicebus%40yahoogroups.com%0b>
> > <mailto:nservicebus%2540yahoogroups.com> > ,
> > > > "Udi Dahan" <thesoftwaresimplist@> wrote:
> > > > >
> > > >
> > > > > Yes - this is still on our roadmap.
> > > > >
> > > > >
> > > > >
> > > >
> > > > > Udi
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > From: nserv...@yahoogroups.com
> <mailto:nservicebus%40yahoogroups.com>
> > <mailto:nservicebus%40yahoogroups.com>
> > <mailto:nservicebus%40yahoogroups.com
> <mailto:nservicebus%40yahoogroups.com%0b>
> > <mailto:nservicebus%2540yahoogroups.com> >
> > > > [mailto:nserv...@yahoogroups.com
> <mailto:nservicebus%40yahoogroups.com>
> > <mailto:nservicebus%40yahoogroups.com>
> > <mailto:nservicebus%40yahoogroups.com
> > <mailto:nservicebus%2540yahoogroups.com> > ]
> > > > On
> > > >
> > > > > Behalf Of pawel.pabich
> > > > > Sent: Sunday, May 27, 2012 5:05 PM
> > > >
> > > > > To: nserv...@yahoogroups.com
> <mailto:nservicebus%40yahoogroups.com>
> <mailto:nservicebus%40yahoogroups.com>
> > <mailto:nservicebus%40yahoogroups.com
> <mailto:nservicebus%40yahoogroups.com%0b>
> > <mailto:nservicebus%2540yahoogroups.com> >
> > > > > Subject: [nservicebus] Re: Multiple endpoints in a single host
> process
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > > Bump. I can't imagine nobody has tried this before.
> > > > >
> > > > > Thanks
> > > > >
> > > > > Pawel
> > > > >
> > > >
> > > > > --- In nserv...@yahoogroups.com
> <mailto:nservicebus%40yahoogroups.com>
> > <mailto:nservicebus%40yahoogroups.com>
> > <mailto:nservicebus%40yahoogroups.com
> <mailto:nservicebus%40yahoogroups.com%0b>
> > <mailto:nservicebus%2540yahoogroups.com> >
> > > > <mailto:nservicebus%40yahoogroups.com
> <mailto:nservicebus%40yahoogroups.com%0b>
> > <mailto:nservicebus%2540yahoogroups.com>
> > > > <mailto:nservicebus%2540yahoogroups.com
> <mailto:nservicebus%2540yahoogroups.com%0b>
)&t=J_3-D_3&al=(as$121j63hpi,aid$9.GrTWKL4I8-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121i91afd,aid$pParTWKL4I8-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121leb50t,aid$UQusTWKL4I8-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
Jeremy Lew
Yeah, I understand the motivations behind lots of assemblies, but it just doesn’t seem to apply here. We’ve been in production for a year without any such issues, and the endpoints are fairly cohesive (by which I mean that they are all providing services to the same application, not integrating a bunch of different systems)
)&t=J_3-D_3&al=(as$121hj8co5,aid$o34YEGKL4M8-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$12146jcu7,aid$hpkYEGKL4M8-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$1211u8j6q,aid$abQYEGKL4M8-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
Jeremy Rosenberg
)&t=J_3-D_3&al=(as$1214n04j9,aid$N3.BHWKL4JI-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121pg76qh,aid$lMyBHWKL4JI-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$12109r7go,aid$8RmCHWKL4JI-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
Ramon Smits
-- Ramon
)&t=J_3-D_3&al=(as$1217v1pu5,aid$IBvrBmKL4NQ-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$12124u66e,aid$kDDrBmKL4NQ-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121mlr34p,aid$AEbrBmKL4NQ-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
Jeremy Rosenberg
)&t=J_3-D_3&al=(as$12101ud6h,aid$TM6GCGKL4JI-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121mulffv,aid$QUqHCGKL4JI-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121sr2kd5,aid$NsaHCGKL4JI-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
Udi Dahan
The gateway is accessible via Bus.SendToSites.
By setting the channel type in the configuration, you can decide which transport (MSMQ, HTTP, etc) will be used to communicate with each site.
For more information, see the documentation here:
http://support.nservicebus.com/customer/portal/articles/859548
Thanks,
Udi
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2904 / Virus Database: 3162/6284 - Release Date: 04/29/13
)&t=J_3-D_3&al=(as$121dv2o30,aid$xgoEDWKL4Go-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$121tb4bu9,aid$8F4EDWKL4Go-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
)&t=J_3-D_3&al=(as$12125u1er,aid$GrMEDWKL4Go-,cr$-1,ct$25,at$H,eob$-1)){kind=small}
clay_shooter
We currently have 3 "virtual" services in the same endpoint each with commands in their own namespaces. Each message producer maps 3 namespaces to (the same) endpoint in their config files.
At some point we might want to split them out without having to reconfigure any of message producers. Multiple endpoints would let us bind the three namespaces to three different named endpoints. This would make service partitioning and service consolidation easy.
Alexey Zimarev
Gateways with HTTP are of no use in my scenario. When I use Azure SB queue, a gateway queue is created there as well. This causes two issues:
- Get an exception that gateway queue cannot be on remote machine
- Even this works all messages will be going via Azure again, traffic problem
Re. “MSMQ, etc” channels as far as I can see in both 3.3.5 and 4.0.0 branches the only implemented channel is HTTP.
Regards,
Alexey
Alexey Zimarev
Kijana,
Checked out your TIBCO sample and also the ISatellite interface along with the Gateway implementation as a satellite. As far as I can see satellites get local queues anyway. This brings me to a complexisity point since I am receiving messages via Azure SB and “local queue” will mean that messages will go to Azure again since this “local queue” will be on Azure SB as well and I don’t want to increase traffic between the local site and Azure.
So I am now thinking to get a forwarder service that will act as NSB endpoint with Azure transport and on transport message mutation it will move messages to the MSMQ without NSB, for the MSMQ endpoint that is running on the same machine to get it as it would be sent from a remote endpoint. For the reverse process I should invent something else because just replying to the message coming this way will not work because the originating address will be Azure endpoint address and will not be reachable via MSMQ.
May be someone has a better suggestion.
Regards,
Alexey
From: nserv...@yahoogroups.com [mailto:nserv...@yahoogroups.com] On Behalf Of kijana.woodard
Sent: 03 May 2013 16:50
To: nserv...@yahoogroups.com
kijana.woodard
The use of the satellite there was for bridging two disparate queueing technologies. If you have the same tech, just route the message normally. You wouldn't need the satellite queue and the "local queue" in that situation.
What am I missing?
--- In nserv...@yahoogroups.com, "Alexey Zimarev" <azimarev@...> wrote:
>
> Kijana,
>
>
>
> Checked out your TIBCO sample and also the ISatellite interface along with
> the Gateway implementation as a satellite. As far as I can see satellites
> get local queues anyway. This brings me to a complexisity point since I am
> receiving messages via Azure SB and "local queue" will mean that messages
> will go to Azure again since this "local queue" will be on Azure SB as well
> and I don't want to increase traffic between the local site and Azure.
>
>
>
> So I am now thinking to get a forwarder service that will act as NSB
> endpoint with Azure transport and on transport message mutation it will move
> messages to the MSMQ without NSB, for the MSMQ endpoint that is running on
> the same machine to get it as it would be sent from a remote endpoint. For
> the reverse process I should invent something else because just replying to
> the message coming this way will not work because the originating address
> will be Azure endpoint address and will not be reachable via MSMQ.
>
>
>
> May be someone has a better suggestion.
>
>
>
> Regards,
>
> Alexey
>
>
>
> From: nserv...@yahoogroups.com [mailto:nserv...@yahoogroups.com] On
> Behalf Of kijana.woodard
> Sent: 03 May 2013 16:50
> To: nserv...@yahoogroups.com
> Subject: [nservicebus] Re: Multiple endpoints in a single host process
>
>
>
>
>
> Satellites are good for this.
>
> --- In nserv...@yahoogroups.com <mailto:nservicebus%40yahoogroups.com> ,
> "Alexey Zimarev" <azimarev@ <mailto:azimarev@> > wrote:
> >
> > My interest in having multiple endpoints in one host was always in
> multiple
> > transport support per endpoint.
> >
> >
> >
> > From: nserv...@yahoogroups.com <mailto:nservicebus%40yahoogroups.com>
> [mailto:nserv...@yahoogroups.com <mailto:nservicebus%40yahoogroups.com> ]
> On
> > Behalf Of Jimmy Bogard
> > Sent: 03 May 2013 15:51
> > To: nserv...@yahoogroups.com <mailto:nservicebus%40yahoogroups.com>
> > Subject: Re: [nservicebus] Re: Multiple endpoints in a single host process
> >
> >
> >
> >
> >
> > Testing would be nice. I wouldn't do this in production, but integration
> > testing and local testing/running would be a lot easier w/o
> > process-per-endpoint.
> >
> >
> >
> > On Thu, May 2, 2013 at 7:00 PM, kijana.woodard <nservicebus@
> <mailto:nservicebus@%0b>
> > <mailto:nservicebus%40yahoogroups.com
> <mailto:nservicebus%40yahoogroups.com%0b>
> > <mailto:nservicebus%2540yahoogroups.com> > ,
> > > > "Udi Dahan" <thesoftwaresimplist@> wrote:
> > > > >
> > > >
> > > > > Yes - this is still on our roadmap.
> > > > >
> > > > >
> > > > >
> > > >
> > > > > Udi
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > From: nserv...@yahoogroups.com
> <mailto:nservicebus%40yahoogroups.com>
> > <mailto:nservicebus%40yahoogroups.com>
> > <mailto:nservicebus%40yahoogroups.com
> <mailto:nservicebus%40yahoogroups.com%0b>
> > <mailto:nservicebus%2540yahoogroups.com> >
> > > > [mailto:nserv...@yahoogroups.com
> <mailto:nservicebus%40yahoogroups.com>
> > <mailto:nservicebus%40yahoogroups.com>
> > <mailto:nservicebus%40yahoogroups.com
> > <mailto:nservicebus%2540yahoogroups.com> > ]
> > > > On
> > > >
> > > > > Behalf Of pawel.pabich
> > > > > Sent: Sunday, May 27, 2012 5:05 PM
> > > >
> > > > > To: nserv...@yahoogroups.com
> <mailto:nservicebus%40yahoogroups.com>
> <mailto:nservicebus%40yahoogroups.com>
> > <mailto:nservicebus%40yahoogroups.com
> <mailto:nservicebus%40yahoogroups.com%0b>
> > <mailto:nservicebus%2540yahoogroups.com> >
> > > > > Subject: [nservicebus] Re: Multiple endpoints in a single host
> process
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > > Bump. I can't imagine nobody has tried this before.
> > > > >
> > > > > Thanks
> > > > >
> > > > > Pawel
> > > > >
> > > >
> > > > > --- In nserv...@yahoogroups.com
> <mailto:nservicebus%40yahoogroups.com>
> > <mailto:nservicebus%40yahoogroups.com>
> > <mailto:nservicebus%40yahoogroups.com
> <mailto:nservicebus%40yahoogroups.com%0b>
> > <mailto:nservicebus%2540yahoogroups.com> >
> > > > <mailto:nservicebus%40yahoogroups.com
> <mailto:nservicebus%40yahoogroups.com%0b>
> > <mailto:nservicebus%2540yahoogroups.com>
> > > > <mailto:nservicebus%2540yahoogroups.com
> <mailto:nservicebus%2540yahoogroups.com%0b>
Alexey Zimarev
Alexey
Jeremy Lew
On Wednesday, October 24, 2012 9:31:47 AM UTC-4, Jeremy Lew wrote:
+1 to this and Jonathan, these are exactly my motivations, particularly the development box F5 and resource usage concerns. I would go a step further and actually not require an AppDomain per endpoint. I'm not sure if my NSB architecture is typical, but I have about 7 services which are the result of breaking out parts of a formerly-monolithic application. Each endpoint does work in one of these categories:
1. Scheduled maintenance/processing jobs
2. Handling of domain events to do eventually-consistent things like full text indexing and provisioning of external systems
3. Handling of long-running processing tasks that require chunking of work in order to stay within transaction timeouts
I think I have decent logical separation, but in fact all of my endpoints end up injecting the same core infrastructure code and talking to the same set of databases (some of them talk to external systems as well.) I have already written my own host (for development boxes) that does the endpoint-per-appdomain thing and it works quite well. However, it still takes at least half a gig of RAM per AppDomain. If I could allocate threads within a single AppDomain to multiple endpoints, I would be a lot better off from the resource usage perspective.
--- In nserv...@yahoogroups.com, Ramon Smits <ramon.smits@...> wrote:
>
> >
> >
> > It seems like it could cause more problems than it solves. Off the top
> > of my head, would we now have to configure which host a handler is for?
> >
>
> I see a multihost as an easy way to start multiple seperated end-points in
> several appdomains. You could easily have subfolders for each app-domain
> and endpoint. Even then it would be easy to have seperated bus instance in
> one appdomain but currently the design of NServiceBus relies on the
> availability of global static's. The container decides how to create a
> handler so each end-point would have its own container and bus instance. It
> would not matter if there would be several in one appdomain or an appdomain
> for each instance. Configuration would stay the same for when you would
> load them in seperate appdomains and I think most easy to achieve as
> Topshelf supports this concept with its 'shelving' feature.
>
> And if you would like to run multiple bus instances thus endpoints in one
> appdomain then you choose if you want to reuse a container
> configuration across bus instances or a bus specific container instance.
>
> Having multiple endpoints in one process does not mean that you have
> logical coupling. It is purely deployment which I think can be very handy.
>
>
> > There are lost of cases where you group multiple AC's into a single
> > package. Think of a composite web app. This isn't logical coupling. Logical
> > coupling has to do with ownership, not where your code source resides or
> > how you choose to package it for deployment. I agree with the convention
> > approach. However, this will be pluggable and the convention approach will
> > probably not be the default.
> >
>
> +1
>
> -- Ramon
>
__._,_.___
.
__,_._,___
Kijana Woodard
--
You received this message because you are subscribed to the Google Groups "Particular Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftw...@googlegroups.com.
To post to this group, send email to particula...@googlegroups.com.
Visit this group at http://groups.google.com/group/particularsoftware.
To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/5b6a14c2-afec-4d1b-9c01-f50969fb7961%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Jeremy Lew
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftware+unsub...@googlegroups.com.
Kijana Woodard
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftw...@googlegroups.com.
To post to this group, send email to particula...@googlegroups.com.
Visit this group at http://groups.google.com/group/particularsoftware.
To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/14ce73f1-013e-4851-bd58-77ae9e653c2e%40googlegroups.com.
Kijana Woodard
Jeremy Lew
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftware+unsubscribe@googlegroups.com.
To post to this group, send email to particula...@googlegroups.com.
Visit this group at http://groups.google.com/group/particularsoftware.
To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/5b6a14c2-afec-4d1b-9c01-f50969fb7961%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Particular Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftware+unsub...@googlegroups.com.
To post to this group, send email to particula...@googlegroups.com.
Visit this group at http://groups.google.com/group/particularsoftware.
Mauro Servienti
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftw...@googlegroups.com.
To post to this group, send email to particula...@googlegroups.com.
Visit this group at http://groups.google.com/group/particularsoftware.
To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/0f1fd1c7-1826-4ec2-b2b6-a3b37559a5b9%40googlegroups.com.
Jeremy Lew
To post to this group, send email to particul...@googlegroups.com.
Mauro Servienti
“What I mean is having multiple queues serving multiple, distinctly-configured, endpoints in a single process”
That’s the key, currently not supported at all. I do not know if there is any plan to support it.
.m
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftw...@googlegroups.com.
To post to this group, send email to particula...@googlegroups.com.
Visit this group at http://groups.google.com/group/particularsoftware.
To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/5b6a14c2-afec-4d1b-9c01-f50969fb7961%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Particular Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftw...@googlegroups.com.
To post to this group, send email to particula...@googlegroups.com.
Visit this group at http://groups.google.com/group/particularsoftware.
To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/14ce73f1-013e-4851-bd58-77ae9e653c2e%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Particular Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftw...@googlegroups.com.
To post to this group, send email to particul...@googlegroups.com.
Visit this group at http://groups.google.com/group/particularsoftware.
To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/0f1fd1c7-1826-4ec2-b2b6-a3b37559a5b9%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Particular Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftw...@googlegroups.com.
To post to this group, send email to
particula...@googlegroups.com.
Visit this group at http://groups.google.com/group/particularsoftware.
To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/0c02fc1e-d11e-4a04-ad70-c5e1942918a9%40googlegroups.com.
Sean Feldman
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftware+unsub...@googlegroups.com.
To post to this group, send email to particula...@googlegroups.com.
Visit this group at http://groups.google.com/group/particularsoftware.
To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/5b6a14c2-afec-4d1b-9c01-f50969fb7961%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Particular Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftware+unsub...@googlegroups.com.
To post to this group, send email to particula...@googlegroups.com.
Visit this group at http://groups.google.com/group/particularsoftware.
To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/14ce73f1-013e-4851-bd58-77ae9e653c2e%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Particular Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftware+unsub...@googlegroups.com.
To post to this group, send email to particul...@googlegroups.com.
Visit this group at http://groups.google.com/group/particularsoftware.
To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/0f1fd1c7-1826-4ec2-b2b6-a3b37559a5b9%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Particular Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftware+unsub...@googlegroups.com.
To post to this group, send email to particul...@googlegroups.com.
Visit this group at http://groups.google.com/group/particularsoftware.
Richard
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftware+unsubscribe@googlegroups.com.
To post to this group, send email to particula...@googlegroups.com.
Visit this group at http://groups.google.com/group/particularsoftware.
To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/5b6a14c2-afec-4d1b-9c01-f50969fb7961%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Particular Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftware+unsub...@googlegroups.com.
To post to this group, send email to particula...@googlegroups.com.
Visit this group at http://groups.google.com/group/particularsoftware.
Jeremy Lew
Mauro Servienti
What's the problem with pub/sub working there? I'm pretty sure an endpoint can subscribe to its own messages, so it ought to work out in that respect.
My issue with it (assuming it does work) is managing the configuration for both types of deployments.
On Friday, January 10, 2014 1:59:26 PM UTC-5, Richard wrote:We're struggling with exactly that. Each service is consuming a ton of memory, almost all of which is the same references (NServiceBus, Entity Framework, Unity, etc., etc.). I've toyed with collapsing services for some deployment scenarios but pub/sub won't work so we'd have to have some nasty workarounds in the code to deal with that. Unless I'm missing something fundamental.