5 Replies Latest reply on Dec 13, 2006 2:57 PM by brian.stansberry

    Tomcat Clustering/JBossCacheService webapp path uniqueness

    laurensvh

      Hi,

      As described in bug http://jira.jboss.com/jira/browse/JBAS-1367 the webapp path is used to create an unique tree node.
      The problem I'm having at the moment is that I have 3 different webapps (with the same virtual host) with the following context paths:

      /aaaa
      /aaaa/bbbb
      /aaaa/cccc

      The first webapp will be cached, but with the other 2 I receive a RegionNotEmptyException and is clustering disabled.

      Anyone an idea how to fix this problem.
      (I have already changed some code in the org.jboss.web.tomcat.tc5.sessionJBossCacheService class, but I prefer a more solid solution ;-)).

      Btw. I'm using JBoss 4.0.4 GA

      Regards,
      Lau

        • 1. Re: Tomcat Clustering/JBossCacheService webapp path uniquene
          brian.stansberry

          Does "aaaa" represent the host name? I'm thinking not, or it should work.

          Are you using FIELD granularity replication? If not, set "UseMarshalling" and "InactiveOnStartup" to false in deploy/tc5-cluster.sar/META-INF/jboss-service.xml.

          If you are using FIELD, your only option is to alter JBossCacheService.start() to escape the webAppPath_ field, replacing the 2nd '/' with some character that's not valid in a context path. This will prevent JBoss Cache from interpreting the '/' as an Fqn divider. (I suspect this is how you already patched it.)

          • 2. Re: Tomcat Clustering/JBossCacheService webapp path uniquene
            laurensvh

            Hi brain,

            Thanks for the quick reply!

            Perhaps I was not clear enough with the context path, but the 'aaaa' is
            part of the context path and not the hostname as you already figured.
            (The real name is 'hypotheek', d.i. dutch for mortgage ;-))

            I've tried both FIELD and ATTRIBUTE granularity (w/ and without the flags
            you mentioned), but with the same results. Looking at the code, the type of
            granularity does not really affects the handling of the context path I think(?)

            At the moment I've added a line with:

            webAppPath_ = webAppPath_.replace("/","_");

            and everythings works fine, but I consider it more of a hack, than a real solution.

            Regards,
            Lau

            • 3. Re: Tomcat Clustering/JBossCacheService webapp path uniquene
              brian.stansberry

              Yeah, the String.replace() is the escaping thing I was talking about. It's a hack, but it's the only solution for a JBossCacheService that needs to integrate with JBoss Cache 1.x. The 1.x API requires passing a string, and JBC is going to parse any '/' as an Fqn element separator.

              The relevance of FIELD is just that if you aren't using it, there is no need to have "UseMarshalling" set to true, and if it's not set to true, the troublesome call to activateRegion() shouldn't happen. You say it happens anyway; I don't understand why that is.

              • 4. Re: Tomcat Clustering/JBossCacheService webapp path uniquene
                laurensvh

                Hi Brian,

                (First I apologize for spelling your name wrong the first time ;-))

                You're absolutely right that this error only happens when setting
                the granularity to FIELD and the marshal flag true. Just checked
                it again with ATTRIBUTE and no errors what so ever. Must have
                overlooked the fact that this aspect worked, since the whole
                clustering doesn't work for me with other granularity than FIELD
                (but that's another story, won't bother you with that).

                Thanks for your help so far!

                Regards,
                Lau

                • 5. Re: Tomcat Clustering/JBossCacheService webapp path uniquene
                  brian.stansberry

                  I didn't even notice the misspelling. :-)

                  I've opened a JIRA for this: http://jira.jboss.com/jira/browse/JBAS-3941.