Re: [Resin-interest] getParameterValues returnes the parameters twice
On Nov 1, 2012, at 6:02 AM, Kaj Hejer wrote: Hi! We have begun seeing that getParameterValues returns each parameter twice. logger.debug(getParameter: + request.getParameter(xxx)); logger.debug(getParameterValues: + Arrays.asList(request.getParameterValues(xxx))); gives DEBUG 21.09.2012 15:35:53:733 (LoginController.java:showForm:33) - getParameter: aaa DEBUG 21.09.2012 15:35:53:733 (LoginController.java:showForm:34) - getParameterValues: [aaa, aaa] for the querystring xxx=aaa Any ideas to why? :) Hi Kaj, I don't think you received a response to this question. This issue is fixed in 4.0.33, which should be released next week. Thanks, Paul I would have excpected that last line to show [aaa] instead of [aaa, aaa]. When running on Jetty we see [aaa]. We are running Resin 4.0.31. -Kaj :) ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest === Paul Cowan, Software Engineer Caucho Technology co...@caucho.com http://blog.caucho.com http://twitter.com/cauchoresin ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Scaling Up
I've used Resin for 6 or 8 years now, ever since working at a company that used it. I use it for a lot of little personal projects and web sites, nothing very substantial. But there's a chance that something I did recently will grow, and I'm looking at how to use Resin with Rackspace virtual hosts. I'm finding it hard to get through some of Caucho's concepts. How is a web server different from an app server? Is a web server the same as a load balancer? All my apps run completely self-contained on a single server, talking to a MySQL instance running on the same machine, using Hibernate and no special caching. I'm having a hard time quickly learning how to move from that environment to the triad and elastic servers. Can I take the intermediate step of running just two servers? How does load balancing work? I've only ever used a Big IP F5. Do I want to bother with Rackspace's load balancers? Stuff like that. Is there a good introductory document (not just a set of slides)? So far, everything I've read assumes a certain level of knowledge. Thanks, -- Rick ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Scaling Up
On 11/8/12 6:11 PM, Rick Mann wrote: I've used Resin for 6 or 8 years now, ever since working at a company that used it. I use it for a lot of little personal projects and web sites, nothing very substantial. But there's a chance that something I did recently will grow, and I'm looking at how to use Resin with Rackspace virtual hosts. I'm finding it hard to get through some of Caucho's concepts. How is a web server different from an app server? Is a web server the same as a load balancer? All my apps run completely self-contained on a single server, talking to a MySQL instance running on the same machine, using Hibernate and no special caching. I'm having a hard time quickly learning how to move from that environment to the triad and elastic servers. Can I take the intermediate step of running just two servers? How does load balancing work? I've only ever used a Big IP F5. Do I want to bother with Rackspace's load balancers? Stuff like that. Is there a good introductory document (not just a set of slides)? So far, everything I've read assumes a certain level of knowledge. We're working on a video that should help. In the meantime: 1) Basically, we start with a single server, just like you're using now. That's an app server because it runs your applications (it also serves static web requests of course.). app_servers : 127.0.0.1:6800 2) Now you either want or need a second app server, either because of load or memory or reliability. That would be two servers. The two servers would be the first two in the triad. The triad stuff happens automatically. The first servers in your list are triad members. In truth, you don't usually need to know about the triad, except you should take a little care to put them on different hardware for reliability. app_servers : 192.168.0.10:6800, 192.168.0.11:6800 (You can also put two Resin servers on one box. Just use the same IP and different ports, like 6801. We use this for testing all the time, and some people do that for reliability or better memory management on one machine.) 3) load balancing But now there's a difficulty because some how the requests need to be shared across the multiple servers, so you need a load balancer of some sort. Resin doesn't care what load balancer you use. We're trying to support whatever configuration you want, assuming that you have a better idea of how you want to balance your own load. Resin's load balancer is mostly provided as an option for medium sites so you don't need to use a hardware load balancer, and because it's easy to configure. (Some sites even use a hardware load balancer in combination with Resin's load balancer.) If you're using a non-Resin load balancer, just point it to the 2 server's http ports. If you're using Resin's load balancer, just add a web_server entry: web_servers : 192.168.1.10:6820 In this case, I put the load balancer on the first machine. That's a perfectly reasonable configuration for a smallish configuration. Make sure all servers are using the same resin.xml and resin.properties. The entire point of Resin's design is to allow you to use a single configuration for your entire cluster. 4) Adding servers. You can keep adding servers to the app_servers list. The first three are automatically the triad. You don't need to do anything special, but if you have different physical servers, it's a good idea to split them for reliability. As long as every server sees that app_servers, the load balancing will just work with the new servers. 5) web vs app tiers. The idea of those two is to mirror the common Apache/Resin or nginx/Resin reverse proxy configuration where you replace Apache with another Resin. You can use that configuration even if you have one app-server. (Benefit is that it isolates the application from the actual network. The penalty is a bit of performance.) The web tier is simple and more reliable because it's only serving HTTP requests and cached data. It also isolates the web from the app tier, because only the web tier needs to worry about things like flaky network connections. When you're using Resin as a load balancer the web tier is the load balancer. 6) The triad. Mostly, it's an internal Resin clustering concept. The main purpose is to handle clustering for fairly large sites that have large variations in load where they want to add or drop servers frequently. The triad servers are the reliable servers. You don't actually need 3. If you have 2, the 2 servers act as backups for each other. The key of the triad is that every other server: 4, 5, 6 can be can be added or dropped whenever you want without affecting things like clustered sessions or caching. For example, you can configure 7 servers, and only have 3 live. Shut down the last 4 and the system just works. But _don't_ shut down the first 3, because that's the triad. That's really the only reason you need to know about the
Re: [Resin-interest] Scaling Up
Thanks, Scott, I'll read through that more carefully shortly. One question. Do I set up one server with the multi-machine additions as you show, and then just replicate the config file (and server, webapp, et al) onto all the machines? I realize that may seem obvious, but I want to be sure. Also, how do I get them to talk to each other via private interfaces? Or does that happen magically with Rackspace? -- Rick On Nov 8, 2012, at 19:08 , Scott Ferguson f...@caucho.com wrote: On 11/8/12 6:11 PM, Rick Mann wrote: I've used Resin for 6 or 8 years now, ever since working at a company that used it. I use it for a lot of little personal projects and web sites, nothing very substantial. But there's a chance that something I did recently will grow, and I'm looking at how to use Resin with Rackspace virtual hosts. I'm finding it hard to get through some of Caucho's concepts. How is a web server different from an app server? Is a web server the same as a load balancer? All my apps run completely self-contained on a single server, talking to a MySQL instance running on the same machine, using Hibernate and no special caching. I'm having a hard time quickly learning how to move from that environment to the triad and elastic servers. Can I take the intermediate step of running just two servers? How does load balancing work? I've only ever used a Big IP F5. Do I want to bother with Rackspace's load balancers? Stuff like that. Is there a good introductory document (not just a set of slides)? So far, everything I've read assumes a certain level of knowledge. We're working on a video that should help. In the meantime: 1) Basically, we start with a single server, just like you're using now. That's an app server because it runs your applications (it also serves static web requests of course.). app_servers : 127.0.0.1:6800 2) Now you either want or need a second app server, either because of load or memory or reliability. That would be two servers. The two servers would be the first two in the triad. The triad stuff happens automatically. The first servers in your list are triad members. In truth, you don't usually need to know about the triad, except you should take a little care to put them on different hardware for reliability. app_servers : 192.168.0.10:6800, 192.168.0.11:6800 (You can also put two Resin servers on one box. Just use the same IP and different ports, like 6801. We use this for testing all the time, and some people do that for reliability or better memory management on one machine.) 3) load balancing But now there's a difficulty because some how the requests need to be shared across the multiple servers, so you need a load balancer of some sort. Resin doesn't care what load balancer you use. We're trying to support whatever configuration you want, assuming that you have a better idea of how you want to balance your own load. Resin's load balancer is mostly provided as an option for medium sites so you don't need to use a hardware load balancer, and because it's easy to configure. (Some sites even use a hardware load balancer in combination with Resin's load balancer.) If you're using a non-Resin load balancer, just point it to the 2 server's http ports. If you're using Resin's load balancer, just add a web_server entry: web_servers : 192.168.1.10:6820 In this case, I put the load balancer on the first machine. That's a perfectly reasonable configuration for a smallish configuration. Make sure all servers are using the same resin.xml and resin.properties. The entire point of Resin's design is to allow you to use a single configuration for your entire cluster. 4) Adding servers. You can keep adding servers to the app_servers list. The first three are automatically the triad. You don't need to do anything special, but if you have different physical servers, it's a good idea to split them for reliability. As long as every server sees that app_servers, the load balancing will just work with the new servers. 5) web vs app tiers. The idea of those two is to mirror the common Apache/Resin or nginx/Resin reverse proxy configuration where you replace Apache with another Resin. You can use that configuration even if you have one app-server. (Benefit is that it isolates the application from the actual network. The penalty is a bit of performance.) The web tier is simple and more reliable because it's only serving HTTP requests and cached data. It also isolates the web from the app tier, because only the web tier needs to worry about things like flaky network connections. When you're using Resin as a load balancer the web tier is the load balancer. 6) The triad. Mostly, it's an internal Resin clustering concept. The main purpose is to handle clustering for fairly large sites that have large variations in load where they want
Re: [Resin-interest] Scaling Up
On Nov 8, 2012, at 19:08 , Scott Ferguson f...@caucho.com wrote: We're working on a video that should help. One more request: I really prefer text descriptions. I find videos excruciatingly difficult to sit through, whereas a well-written textual how-to allows me to skim over parts I'm familiar with. One of the keys to making it well-written is to put the actual steps to carry out in a bullet-point or numbered list, so that a crucial bit of info isn't buried in a paragraph somewhere. Thanks! -- Rick ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Scaling Up
On 11/8/12 7:17 PM, Rick Mann wrote: Thanks, Scott, I'll read through that more carefully shortly. One question. Do I set up one server with the multi-machine additions as you show, and then just replicate the config file (and server, webapp, et al) onto all the machines? I realize that may seem obvious, but I want to be sure. Yes, all the servers will have the same configuration. Also, how do I get them to talk to each other via private interfaces? Or does that happen magically with Rackspace? Ah. I wasn't explicit about that. (You're right about assumptions.) The IP addresses you put in app_servers and web_servers are *private* addresses. You shouldn't put public addresses in the app_servers and web_servers, if you have the option. If you have 1 machine, you should use 127.0.0.1, otherwise use the private IP. I don't specifically know about Rackspace, but you might need to change the firewall settings so each server is allowed to connect to 6800. Amazon, for example, has a security group firewall, so only the servers in the security group are allowed to see 6800. Outside servers can't get to it. I'm sure Rackspace has something similar. When you start Resin with start-all (or the /etc/init.d script), Resin will compare its own IP address with the configuration IP addresses in app_servers and web_servers and start itself as the local address. (Does that make sense?) -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Scaling Up
On Nov 8, 2012, at 19:28 , Scott Ferguson f...@caucho.com wrote: Yes, all the servers will have the same configuration. Okay, so, I can set one up with the config, make a snapshot of that machine, then bring up more instances from that snapshot. I'll have to figure out how to manage the IP addresses of the hosts that I bring up; might have to manually edit the config file after they're brought up. Similar question for elastic servers. Also, how do I get them to talk to each other via private interfaces? Or does that happen magically with Rackspace? Ah. I wasn't explicit about that. (You're right about assumptions.) :-) The IP addresses you put in app_servers and web_servers are *private* addresses. You shouldn't put public addresses in the app_servers and web_servers, if you have the option. If you have 1 machine, you should use 127.0.0.1, otherwise use the private IP. I don't specifically know about Rackspace, but you might need to change the firewall settings so each server is allowed to connect to 6800. Amazon, for example, has a security group firewall, so only the servers in the security group are allowed to see 6800. Outside servers can't get to it. I'm sure Rackspace has something similar. Yes, I remember dealing with that on EC2, I'll figure out what Rackspace does. I did find the two IPs, internal and external. One thing that's becoming clear is what was listening on 6800 vs 80: 6800 is for internal communication among servers. Not sure if it's used in the single-server case, but I understand. When you start Resin with start-all (or the /etc/init.d script), Resin will compare its own IP address with the configuration IP addresses in app_servers and web_servers and start itself as the local address. (Does that make sense?) Yes, I think so. After I make some dinner I'll try to go through your original email and get a couple servers running. The first server will be my load balancer, which will hit itself and the other server. MySQL can sit on the first server (although I imagine in that configuration, it might make sense for it to sit on the other server, since the first has the added burden of being the load balancer). Thanks! I'm rather excited to try running multiple machines, and see how badly my code breaks. -- Rick ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Scaling Up
On 11/8/12 7:39 PM, Rick Mann wrote: On Nov 8, 2012, at 19:28 , Scott Ferguson f...@caucho.com wrote: Yes, all the servers will have the same configuration. Okay, so, I can set one up with the config, make a snapshot of that machine, then bring up more instances from that snapshot. I'll have to figure out how to manage the IP addresses of the hosts that I bring up; might have to manually edit the config file after they're brought up. Yep. If the IP addresses are random, like Amazon, Resin has a few tricks to help, but that's a complication that's not necessary if you can rely on an IP address. Similar question for elastic servers. You do have to tweak the config for the first elastic server, but after that you can take a snapshot of the elastic server and just bring up lots of instances with the new snapshot without changing the configuration. Yes, I remember dealing with that on EC2, I'll figure out what Rackspace does. I did find the two IPs, internal and external. One thing that's becoming clear is what was listening on 6800 vs 80: 6800 is for internal communication among servers. Not sure if it's used in the single-server case, but I understand. Exactly. When you start Resin with start-all (or the /etc/init.d script), Resin will compare its own IP address with the configuration IP addresses in app_servers and web_servers and start itself as the local address. (Does that make sense?) Yes, I think so. After I make some dinner I'll try to go through your original email and get a couple servers running. The first server will be my load balancer, which will hit itself and the other server. MySQL can sit on the first server (although I imagine in that configuration, it might make sense for it to sit on the other server, since the first has the added burden of being the load balancer). Thanks! I'm rather excited to try running multiple machines, and see how badly my code breaks. Hopefully, it won't even notice :) -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
