Re: Plan to add sandbox branch
Hmmm... this has me thinking about maybe using the provider interface to implement the communication mechanism... let me mull this over. > On Nov 30, 2018, at 8:27 AM, Jim Jagielski wrote: > > Yeah, I looked for something else, esp various pubsub implementations, but > they really didn't fit in with what was needed. > > >> On Nov 29, 2018, at 3:02 AM, jean-frederic clere wrote: >> >> On 29/11/2018 07:02, Christophe JAILLET wrote: >>> Le 28/11/2018 à 02:33, Daniel Ruggeri a écrit : Hi, Jim; I'm coming up empty on a search against the Google-machine for SURVEY protocol. Any pointers you can share? >>> Hi >>> >>> Not sure if the answers already posted are what you are looking for. >>> Here are some links: >>> https://nanomsg.org/gettingstarted/survey.html and other resources on >>> https://nanomsg.org/ >>> >>> >>> CJ >>> >> >> So as I am looking to proxy tomcat using httpd I need a 'pure" java >> implementation for tomcat, it seems that it is missing for the moment, >> correct? >> >> -- >> Cheers >> >> Jean-Frederic >
Re: Plan to add sandbox branch
Yeah, I looked for something else, esp various pubsub implementations, but they really didn't fit in with what was needed. > On Nov 29, 2018, at 3:02 AM, jean-frederic clere wrote: > > On 29/11/2018 07:02, Christophe JAILLET wrote: >> Le 28/11/2018 à 02:33, Daniel Ruggeri a écrit : >>> Hi, Jim; >>> I'm coming up empty on a search against the Google-machine for SURVEY >>> protocol. Any pointers you can share? >>> >> Hi >> >> Not sure if the answers already posted are what you are looking for. >> Here are some links: >>https://nanomsg.org/gettingstarted/survey.html and other resources on >> https://nanomsg.org/ >> >> >> CJ >> > > So as I am looking to proxy tomcat using httpd I need a 'pure" java > implementation for tomcat, it seems that it is missing for the moment, > correct? > > -- > Cheers > > Jean-Frederic
Re: Plan to add sandbox branch
On 27.11.2018. 12:23, Jim Jagielski wrote: In the coming week or so, I will be committing my load balance, load determination and discovery work to a sandbox trunk. Many people have asked for more info, so here we go. Thanks for the info. Like said, I'm for the idea for advertise/register/unregister dynamic approach. Having a basic working implementation, other could add more complex features and implement additional strategies. Thus ++1 Regards -- ^TM
Re: Plan to add sandbox branch
On 29/11/2018 07:02, Christophe JAILLET wrote: > Le 28/11/2018 à 02:33, Daniel Ruggeri a écrit : >> Hi, Jim; >> I'm coming up empty on a search against the Google-machine for SURVEY >> protocol. Any pointers you can share? >> > Hi > > Not sure if the answers already posted are what you are looking for. > Here are some links: > https://nanomsg.org/gettingstarted/survey.html and other resources on > https://nanomsg.org/ > > > CJ > So as I am looking to proxy tomcat using httpd I need a 'pure" java implementation for tomcat, it seems that it is missing for the moment, correct? -- Cheers Jean-Frederic
Re: Plan to add sandbox branch
Le 28/11/2018 à 02:33, Daniel Ruggeri a écrit : Hi, Jim; I'm coming up empty on a search against the Google-machine for SURVEY protocol. Any pointers you can share? Hi Not sure if the answers already posted are what you are looking for. Here are some links: https://nanomsg.org/gettingstarted/survey.html and other resources on https://nanomsg.org/ CJ
Re: Plan to add sandbox branch
How often are nodes updating themselves? Are they only updating their main proxy server or each other in a “multicast” fashion? How about if one of the nodes crash before sending back an update? Are you locking a session to a specific backend host, keep it tracked on the proxy/front end server and if so, for how long? When I read your message, in particular the STATUS info statement, this plan of yours looked to me like how a regular load balancer product works, and if that is the intent, how different from and/or how integrated to ATS is this going to be? Alex On 2018/11/27 11:23:25, Jim Jagielski wrote: > In the coming week or so, I will be committing my load balance,> > load determination and discovery work to a sandbox trunk. Many> > people have asked for more info, so here we go.> > > Basically, this new feature uses nanomsg (nng) to implement the> > SURVEY protocol between workers (nodes) and the front end server.> > The proxy server will send out MEMBERSHIP and STATUS surveys, that> > nodes can respond to; thus new nodes can automagically add themselves> > as they come up as well as remove themselves when they restart or> > shutdown via MEMBERSHIP. STATUS can be used to provide real-time> > load on each node, which will be sent via a __packed__ struct,> > ala NTP and other common usage patterns, in which 32bit fields are> > converted from endian-ness to network and back. That STATUS info can> > be used for "intelligent" load balancing and will provide some> > typical server metrics such as memory, # of cpus, etc...> > smime.p7s Description: S/MIME cryptographic signature
Re: Plan to add sandbox branch
https://nanomsg.org > On Nov 27, 2018, at 8:33 PM, Daniel Ruggeri wrote: > > Hi, Jim; > I'm coming up empty on a search against the Google-machine for SURVEY > protocol. Any pointers you can share? > > I'm also curious what your thoughts are about dealing with growth of the > worker pool beyond the control of the proxy admin. For example, if I > configure a balancer for 10 nodes, I have an idea of tuning parameters I > might set differently than if the number of backends is in the tens of > servers. Since nanomsg/nng will provide the communication between httpd and the backends, we could add something like a CONFIG survey that allows for the backends to "suggest" params. > -- > Daniel Ruggeri > > On November 27, 2018 5:23:25 AM CST, Jim Jagielski wrote: > In the coming week or so, I will be committing my load balance, > load determination and discovery work to a sandbox trunk. Many > people have asked for more info, so here we go. > > Basically, this new feature uses nanomsg (nng) to implement the > SURVEY protocol between workers (nodes) and the front end server. > The proxy server will send out MEMBERSHIP and STATUS surveys, that > nodes can respond to; thus new nodes can automagically add themselves > as they come up as well as remove themselves when they restart or > shutdown via MEMBERSHIP. STATUS can be used to provide real-time > load on each node, which will be sent via a __packed__ struct, > ala NTP and other common usage patterns, in which 32bit fields are > converted from endian-ness to network and back. That STATUS info can > be used for "intelligent" load balancing and will provide some > typical server metrics such as memory, # of cpus, etc...
Re: Plan to add sandbox branch
On 11/28/2018 02:33 AM, Daniel Ruggeri wrote: > Hi, Jim; > I'm coming up empty on a search against the Google-machine for SURVEY > protocol. Any pointers you can share? > > I'm also curious what your thoughts are about dealing with growth of the > worker pool beyond the control of the proxy admin. For example, if I configure > a balancer for 10 nodes, I have an idea of tuning parameters I might set > differently than if the number of backends is in the tens of servers. > -- > Daniel Ruggeri Mod_cluster solves this with configuration messages from worker nodes. Httpd with mod_cluster configures balancers (as in mod_proxy balancer lingo) according to CONFIG messages from workers. So if you are spinning up a new batch of workers, you might tell them to configure balancer differently, different timeout or retry values for example. Cheers K. > > On November 27, 2018 5:23:25 AM CST, Jim Jagielski wrote: > > In the coming week or so, I will be committing my load balance, > load determination and discovery work to a sandbox trunk. Many > people have asked for more info, so here we go. > > Basically, this new feature uses nanomsg (nng) to implement the > SURVEY protocol between workers (nodes) and the front end server. > The proxy server will send out MEMBERSHIP and STATUS surveys, that > nodes can respond to; thus new nodes can automagically add themselves > as they come up as well as remove themselves when they restart or > shutdown via MEMBERSHIP. STATUS can be used to provide real-time > load on each node, which will be sent via a __packed__ struct, > ala NTP and other common usage patterns, in which 32bit fields are > converted from endian-ness to network and back. That STATUS info can > be used for "intelligent" load balancing and will provide some > typical server metrics such as memory, # of cpus, etc... > Michal Karm Babacek -- Sent from my Hosaka Ono-Sendai Cyberspace 7
Re: Plan to add sandbox branch
Hi, Jim; I'm coming up empty on a search against the Google-machine for SURVEY protocol. Any pointers you can share? I'm also curious what your thoughts are about dealing with growth of the worker pool beyond the control of the proxy admin. For example, if I configure a balancer for 10 nodes, I have an idea of tuning parameters I might set differently than if the number of backends is in the tens of servers. -- Daniel Ruggeri On November 27, 2018 5:23:25 AM CST, Jim Jagielski wrote: >In the coming week or so, I will be committing my load balance, >load determination and discovery work to a sandbox trunk. Many >people have asked for more info, so here we go. > >Basically, this new feature uses nanomsg (nng) to implement the >SURVEY protocol between workers (nodes) and the front end server. >The proxy server will send out MEMBERSHIP and STATUS surveys, that >nodes can respond to; thus new nodes can automagically add themselves >as they come up as well as remove themselves when they restart or >shutdown via MEMBERSHIP. STATUS can be used to provide real-time >load on each node, which will be sent via a __packed__ struct, >ala NTP and other common usage patterns, in which 32bit fields are >converted from endian-ness to network and back. That STATUS info can >be used for "intelligent" load balancing and will provide some >typical server metrics such as memory, # of cpus, etc...
