On Mon, Feb 18, 2019 at 12:27 PM John Dale <jcdw...@gmail.com> wrote:
> Regarding clustering and state recovery, I opted some time ago to > store session information in the database - I prefer full control over > session state for security/obscurity reasons. > > Load balancing is straightforward this way. > > I'm not sure I would ever need more than 2 nodes for my purposes, > though, since Java can address such a huge memory space. It's an > amazing computing environment now compared to what we had 20 years > ago. > Thanks John, this is my motivation. I really want the insight and load balancing capability. Do you use Redis for the DB or other? HB > > On 2/18/19, Christopher Schultz <ch...@christopherschultz.net> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > Herb, > > > > On 2/18/19 13:59, Herb Burnswell wrote: > >> On Fri, Feb 15, 2019 at 12:21 PM Christopher Schultz < > >> ch...@christopherschultz.net> wrote: > >> > >> Herb, > >> > >> On 2/14/19 12:41, Herb Burnswell wrote: > >>>>> Tomcat 8.5.23 RHEL 7.5 > >>>>> > >>>>> We are looking to set up session management via Redisson to > >>>>> offload the CPU consumption of using Tomcat's built in > >>>>> clustering session management. We have CPU licensing limits > >>>>> and need to conserve as much CPU as possible. > >> > >> Dumb question: aren't you just going to move the CPU cycles to > >> another system? > >> > >> > >>> Thanks for the reply. Short answer, yes. But that is the idea. > >>> We can only use 2 CPU's per application node (3 nodes) with our > >>> licensing structure so we do not want to take cycles away from > >>> the application to manage sessions. > > > > Okay, so if you move the session-management to another machine, you > > don't have to pay app-license fees for the session-management server? > > Fair enough. > > > > Just remember that you still need code "managing" sessions from your > > Tomcat note to your Redisson server. I can't imagine that the > > Tomcat->Resisson code would be any less complicated than the Tomcat -> > > Tomcat code. You might want to validate that assumption before > > committing any resources toward solving a problem by adding complexity > > to your deployments. > > > >> Another dumb question: do you actually need clustering? > >> > >> > >>> If I'm using the term correctly, yes. The idea would be for HA > >>> functionality; If users were connected to node 3 and the node > >>> failed for some reason, their session would be picked up by node > >>> 1 or 2 uninterrupted. Sorry if I confused the intent. > > > > That's exactly what you will get. > > > > If you do NOT use clustering, a failed node will require the users who > > were on the failed node to re-login to a surviving node. Only you can > > determine whether that is an acceptable consequence of a failed node > > for your users and application. I, as well as many others, have > > decided that fail-over is such a rare event and logins such a > > non-issue that introducing the complexity of clustering is not justified > > . > > > >>>>> I have never set up a configuration this way, however I have > >>>>> Redis set up and running as 1 Master, 1 Slave. I seemingly > >>>>> just need to point our application to it. I have read this > >>>>> doc on how to: > >>>>> > >>>>> https://github.com/redisson/redisson/tree/master/redisson-tomcat > >>>>> > >>>>> > >>>>> > > It seems pretty straight forward except for the redisson.conf > >>>>> configuration: > >>>>> > >>>>> Add RedissonSessionManager into tomcat/conf/context.xml > >>>>> > >>>>> <Manager > >>>>> className="org.redisson.tomcat.RedissonSessionManager" > >>>>> configPath="${catalina.base}/redisson.conf" readMode="REDIS" > >>>>> updateMode="DEFAULT"/> > >> > >> I would do this in the application's context.xml file instead of > >> the global/default one. That means modifying the application's > >> META-INF/context.xml file, or, if you deploy via files from > >> outside your WAR/dir application, then > >> conf/[engine]/[hostname]/[appname].xml. > >> > >> > >>> Yes, this is requiring the editing a application specific xml > >>> file. > > > > Good. > > > >>>>> I am more familiar with YAML so plan on configuring the > >>>>> redisson.conf as such. I have read the referenced > >>>>> configuration wiki page: > >>>>> > >>>>> https://github.com/redisson/redisson/wiki/2.-Configuration > >>>>> > >>>>> However, it has a great deal of options and I'm not sure what > >>>>> is and is not needed. > >>>>> > >>>>> I am reaching out here on the Tomcat user group to see if > >>>>> anyone else is using Redisson for session management and if > >>>>> maybe I can get some guidance on a basic redisson.conf > >>>>> configuration. I'd also be interested in comments on if > >>>>> there are better options or things to watch out for. > >> > >> I don't have any experience with either Redis or Redisson, but what > >> is wrong with the default/sample configuration you have provided > >> above? > >> > >> > >>> I have through much trial and error been using this config: > >> > >>> { "masterSlaveServersConfig":{ "idleConnectionTimeout":10000, > >>> "connectTimeout":10000, "timeout":3000, "retryAttempts":3, > >>> "retryInterval":1500, "failedSlaveReconnectionInterval":3000, > >>> "failedSlaveCheckInterval":60000, "password":"<master_pass>", > >>> "subscriptionsPerConnection":5, "clientName":true, > >>> "subscriptionConnectionMinimumIdleSize":1, > >>> "subscriptionConnectionPoolSize":50, > >>> "slaveConnectionMinimumIdleSize":32, > >>> "slaveConnectionPoolSize":64, > >>> "masterConnectionMinimumIdleSize":32, > >>> "masterConnectionPoolSize":64, "readMode":"SLAVE", > >>> "subscriptionMode":"SLAVE", "slaveAddresses":[ > >>> "<slave.example.com:6379" ], > >>> "masterAddress":"<master.example.com>:6379", "database":0 }, > >>> "threads":0, "nettyThreads":0, "transportMode":"NIO" } > >> > >>> However, I am getting a couple exceptions and am not sure what > >>> might be the issue: > > > > Okay, let's take a look: > > > >>> INFO | jvm 1 | main | 2019/02/18 10:09:33.068 | Feb 18, > >>> 2019 10:09:33 AM org.apache.catalina.core.StandardContext > >>> startInternal INFO | jvm 1 | main | 2019/02/18 > >>> 10:09:33.068 | SEVERE: The session manager failed to start > > > > Wow, this stack trace is tough to read. :( > > > >>> INFO | jvm 1 | main | 2019/02/18 10:09:33.068 | > >>> org.apache.catalina.LifecycleException: Failed to start > >>> component [org.redisson.tomcat.RedissonSessionManager[]] INFO | > >>> jvm 1 | main | 2019/02/18 10:09:33.068 | at > >>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:167) > >>> > >>> > > INFO | jvm 1 | main | 2019/02/18 10:09:33.068 | at > >>> org.apache.catalina.core.StandardContext.startInternal(StandardContex > > t.java:5224) > >>> > >>> > > INFO | jvm 1 | main | 2019/02/18 10:09:33.068 | at > >>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > >>> > >>> > > INFO | jvm 1 | main | 2019/02/18 10:09:33.068 | at > >>> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase. > > java:1419) > >>> > >>> > > INFO | jvm 1 | main | 2019/02/18 10:09:33.068 | at > >>> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase. > > java:1409) > >>> > >>> > > INFO | jvm 1 | main | 2019/02/18 10:09:33.068 | at > >>> java.util.concurrent.FutureTask.run(FutureTask.java:266) INFO | > >>> jvm 1 | main | 2019/02/18 10:09:33.068 | at > >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. > > java:1149) > >>> > >>> > > INFO | jvm 1 | main | 2019/02/18 10:09:33.068 | at > >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor > > .java:624) > >>> > >>> > > INFO | jvm 1 | main | 2019/02/18 10:09:33.068 | at > >>> java.lang.Thread.run(Thread.java:748) INFO | jvm 1 | main > >>> | 2019/02/18 10:09:33.068 | Caused by: > >>> org.apache.catalina.LifecycleException: > >>> java.lang.NullPointerException INFO | jvm 1 | main | > >>> 2019/02/18 10:09:33.068 | at > >>> org.redisson.tomcat.RedissonSessionManager.buildClient(RedissonSessio > > nManager.java:279) > >>> > >>> > > INFO | jvm 1 | main | 2019/02/18 10:09:33.068 | at > >>> org.redisson.tomcat.RedissonSessionManager.startInternal(RedissonSess > > ionManager.java:209) > > > > It > >>> > > looks like your SessionManager (from Redisson) is failing to start > > up. If you can look at the source, you might be able to see some kind > > of missing configuration parameter and fix it. Or you could ask the > > Redisson community what you might be missing. I've never even heard of > > Redisson and I've been on this list for ... 15 years. Perhaps someone > > else here can chime-in and help, but I wouldn't bet on it. > > > > Or there could be a bug in Redisson. For that, you'll have to approach > > that community for help, of course. I would consider a SessionManager > > throwing an NPE to be a bug. If there is some kind of required > > configuration, the SessionManager should emit a helpful message like > > "masterAddress is required" or somesuch. > > > >>> INFO | jvm 1 | main | 2019/02/18 10:09:33.068 | > >>> at > >>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > >>> > >>> > > INFO | jvm 1 | main | 2019/02/18 10:09:33.068 | ... 8 mo > > re > >>> INFO | jvm 1 | main | 2019/02/18 10:09:33.068 | Caused > >>> by: java.lang.NullPointerException > > > > Hmm, the plot thickens. The NPE is not in the SessionManager; it's in > > the netty client? > > > >>> INFO | jvm 1 | main | 2019/02/18 10:09:33.068 | > >>> at io.netty.util.NetUtil.isValidIpV4Address(NetUtil.java:648) > >>> INFO | jvm 1 | main | 2019/02/18 10:09:33.068 | > >>> at > >>> io.netty.util.NetUtil.createByteArrayFromIpAddressString(NetUtil.java > > :368) > >>> > >>> > > INFO | jvm 1 | main | 2019/02/18 10:09:33.068 | at > >>> org.redisson.client.RedisClient.resolveAddr(RedisClient.java:172) > >>> > >>> > > INFO | jvm 1 | main | 2019/02/18 10:09:33.068 | at > >>> org.redisson.connection.MasterSlaveEntry.addSlave(MasterSlaveEntry.ja > > va:303) > >>> > >>> > > INFO | jvm 1 | main | 2019/02/18 10:09:33.068 | at > >>> org.redisson.connection.MasterSlaveEntry.addSlave(MasterSlaveEntry.ja > > va:345) > >>> > >>> > > INFO | jvm 1 | main | 2019/02/18 10:09:33.068 | at > >>> org.redisson.connection.MasterSlaveEntry.initSlaveBalancer(MasterSlav > > eEntry.java:102) > >>> > >>> > > INFO | jvm 1 | main | 2019/02/18 10:09:33.068 | at > >>> org.redisson.connection.MasterSlaveConnectionManager.createMasterSlav > > eEntry(MasterSlaveConnectionManager.java:372) > >>> > >>> > > INFO | jvm 1 | main | 2019/02/18 10:09:33.068 | at > >>> org.redisson.connection.MasterSlaveConnectionManager.initSingleEntry( > > MasterSlaveConnectionManager.java:346) > >>> > >>> > > INFO | jvm 1 | main | 2019/02/18 10:09:33.068 | at > >>> org.redisson.connection.MasterSlaveConnectionManager.<init>(MasterSla > > veConnectionManager.java:161) > >>> > >>> > > INFO | jvm 1 | main | 2019/02/18 10:09:33.068 | at > >>> org.redisson.config.ConfigSupport.createConnectionManager(ConfigSuppo > > rt.java:225) > >>> > >>> > > INFO | jvm 1 | main | 2019/02/18 10:09:33.068 | at > >>> org.redisson.Redisson.<init>(Redisson.java:121) INFO | jvm 1 > >>> | main | 2019/02/18 10:09:33.068 | at > >>> org.redisson.Redisson.create(Redisson.java:164) INFO | jvm 1 > >>> | main | 2019/02/18 10:09:33.068 | at > >>> org.redisson.tomcat.RedissonSessionManager.buildClient(RedissonSessio > > nManager.java:277) > >>> > >>> > > INFO | jvm 1 | main | 2019/02/18 10:09:33.068 | ... 10 m > > ore > >>> INFO | jvm 1 | main | 2019/02/18 10:09:33.068 | INFO | > >>> jvm 1 | main | 2019/02/18 10:09:33.068 | Feb 18, 2019 > >>> 10:09:33 AM org.apache.catalina.core.StandardContext > >>> startInternal INFO | jvm 1 | main | 2019/02/18 > >>> 10:09:33.068 | SEVERE: Context [] startup failed due to previous > >>> errors > > > > Yep, the issue is in the Netty client. It's failing while trying to > > validate an IP address. Specifically for a slave's address (I gather > > from reading the stack trace). Are you sure anything that looks like > > it should be an IP address is correct? Can slaveAddresses have a port > > number? Are there other "address" type configuration parameters that > > must be set but that you haven't set to something? Maybe a port number? > > > > I still think an NPE is a very non-graceful handling, here, and I > > would expect that the SessionManager would perform a sanity-check on > > all values -- especially if they are required -- before using them to > > e.g. make a network connection. > > > > Hope that helps, > > - -chris > > -----BEGIN PGP SIGNATURE----- > > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxrBsIACgkQHPApP6U8 > > pFg+Tg/+N3In8g4bowjSYL/qe+tPH/4S67FQQgK+Gh+JRtRB4SgJ0ie3N7OVr1OP > > AculZNMIqDL2IkpFCRWOyctZSAh6dznzvy99CT1rLscEy1WYTwL93sPaEWrPGFsB > > 1WuxdbPkONrG8D4PSDCe9714cj4yTmz6v7nXR1Oii3G6tu+0V+hg6bT5ton4Pw/K > > uoDbsPKvg9f5nuGaVpG1ukHFxIANV3ShmJDmjDKcAypaNsOS7Fmsst6EeiZfmTjy > > vZtLPBydzL+bgEhTdXdRXEcqmkA1QVA8HS8XtI9aXFhY5kdjs0U1ebiwoPz8k6Ln > > NPd0js8FNO5GUhdJuCbOPEzkqRuLyR8hIdtyHQ1dJnJpOs0LtYoEEb5s+arIwuQX > > rSvMfrIlOB9Za1fu03MGcHETDXqPR8ZHzHezqf8cxGUIrMKO0ZOQmkuC1SZA7O1v > > HO2jQjiipXw2gQ00qM+9yruYyp5Dgf0qHS+5uy38ueBqcIw/cEgOGq8xgYB7qCNR > > f4pkpTvvZvARpGTZFrCwvRvsovtdjpA6iNKElFZJXcN+F7kRa9/Kx4voOpbnLtJk > > Pmu8ciFrZ1xtPCpYMOlY6+HcyIMfS3ip5qFm5ATPu4sqNtarzIRsWt7hfw8qTU64 > > etq2KDiGW8O0SAiuuCpZda47Bfg8A0wN9uEjJxiVznHIT8K+89E= > > =xIZ2 > > -----END PGP SIGNATURE----- > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
