10 Replies Latest reply on Jun 8, 2005 2:51 AM by belaban

    Using jboss-cache outside of JBoss

    magellan94

       

      "magellan94" wrote:
      What is required to use jboss-cache outside of JBoss? Jboss-cache is J2EE agnostic, so theoretically it needn't be deployed within an application server. Is it possible to deploy a distributed cache that is shared by a servlet in a cluster of webservers (tomcat, for instance) as well as an EJB running on JBoss?

      Here is the extra credit section. What do you think about deploying jboss-cache on application servers other than JBoss? My company is developing an application that requires support for multiple application servers. I am searching for a distributed caching solution that can operate inside and outside an application server. I'd be excited to use jboss-cache and lend development support if it's possible for it to meet these needs.

      Thanks, Dave


        • 1. Re: Using jboss-cache outside of JBoss
          belaban

          Hi Dave,


          > What is required to use jboss-cache outside of
          > JBoss?

          Currently I make use of the MBeanServiceSupport interface (start(), stop(), create() and desroy()). So you can already run TreeCacheView standalone.

          However, the change I want to make is to base TreeCache on the JBoss Cluster subsystem (which is based on JavaGroups) instead of using JavaGroups directly (as is currently done).

          Also, once AOP comes into play, we will have another dependency on JBoss.


          > Jboss-cache is J2EE agnostic, so theoretically it
          > needn't be deployed within an application server. Is
          > it possible to deploy a distributed cache that is
          > shared by a servlet in a cluster of webservers
          > (tomcat, for instance) as well as an EJB running on
          > JBoss?


          Currently, yes. In the future, I don'y know. I'll try to always run it standalone, but I may want to make use of some of the services JBoss offers (such as AOP).



          > Here is the extra credit section. What do you think
          > about deploying jboss-cache on application servers
          > other than JBoss?

          This should be possible.

          > My company is developing an
          > application that requires support for multiple
          > application servers. I am searching for a distributed
          > caching solution that can operate inside and
          > outside an application server.


          I think this should be possible. The only dependencies of the cache is
          - JavaGroups (this can be run independent of JBoss)

          or

          - The clustering subsystem of JBoss.

          - AOP. But the cache won't use AOP; rather AOP will be a client of the cache, so that should work too.


          > I'd be excited to use
          > jboss-cache and lend development support if it's
          > possible for it to meet these needs.

          Check out the first version of TreeCache and see whether it'll fit your bill. I'll put out some preliminary documentation Monday,


          Bela

          • 2. Re: Using jboss-cache outside of JBoss
            marc.fleury

            dude!

            remember that JBoss is a microkernel so the precise answer to your question is you don't need JBoss to run the cache. You don't need EJB's specifically.

            You still need the microkernel, the deployers, and most likely the AOP framework for the 4.0 version but no you don't need J2EE to do it.

            • 3. Re: Using jboss-cache outside of JBoss
              belaban

              His question war more like "can you use the cache in a different appserver".

              My take on it: probably yes. At least I'm striving to make the cache appserver agnostic, e.g. by making the cache JCache compliant (whenever they come out with the spec)

              That said, you will miss some of the value-add features that you get when running the cache inside JBoss, e.g. AOP.
              Bela

              • 4. Re: Using jboss-cache outside of JBoss
                magellan94

                Hi, Bela. Thanks to all for the helpful responses. After browsing the source code, I'm hoping TreeCache will satisfy my needs nicely. However, I'm concerned about the way JavaGroups creates threads and network sockets to handle each layer of the protocol stack.

                The EJB 2.0 specification imposes a few restrictions on the code used by EJBs. Two of these restrictions involve threading and network connections. Here are the relevant sections copied from the EJB spec.

                <ejb-spec>
                • An enterprise Bean must not use thread synchronization primitives to synchronize execution of
                multiple instances.

                This rule is required to ensure consistent runtime semantics because while some EJB Containers may
                use a single JVM to execute all enterprise bean's instances, others may distribute the instances across
                multiple JVMs . . . Synchronization would not work if the EJB Container distributed enterprise
                bean's instances across multiple JVMs.

                • An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or
                use a socket for multicast.

                The EJB architecture allows an enterprise bean instance to be a network socket client, but it does not
                allow it to be a network server. Allowing the instance to become a network server would conflict with
                the basic function of the enterprise bean-- to serve the EJB clients.
                </ejb-spec>

                I'm pretty sure that this restriction is designed to discourage developers from implementing a waiting server thread that dispatches to worker threads, which the container's responsibility. Nevertheless, calling a cache that uses javagroups would clearly violate the literal meaning of these restrictions. Should I be concerned about accessing a TreeCache from within an EJB?

                Thanks,
                Dave

                • 5. Re: Using jboss-cache outside of JBoss
                  belaban

                  Hi Dave,

                  > Hi, Bela. Thanks to all for the helpful responses.
                  > After browsing the source code, I'm hoping TreeCache
                  > will satisfy my needs nicely.


                  Please note that this is 'fresh' code, until about 2 days ago it only compiled, but didn't run yet. Yesterday night I fixed a couple of bugs and tested the transient and repl-async modes a bit. The next step is now to write unit test cases which test the use cases outlined in the TreeCache document.


                  > However, I'm concerned about the way JavaGroups creates threads
                  > and network sockets to handle each layer of the protocol stack.

                  Don't be ! You can remove a large number of threads used by JavaGroups by simply giving it a different configuration, this is totally deployment dependent. If you want to go crazy you can disable almost all threads, but at the expense of concurrency.


                  > The EJB 2.0 specification imposes a few restrictions
                  > on the code used by EJBs. Two of these restrictions
                  > involve threading and network connections.

                  Yes, that's true for beans. However, the TreeCache is part of the JBoss server, so the functionality which *implements* JBoss. It is not a bean itself (well, it *is* an MBean, but the points below don't apply to MBeans).




                  > <ejb-spec>
                  > • An enterprise Bean must not use thread
                  > synchronization primitives to synchronize execution
                  > of multiple instances.

                  The cache is *not* an enterprise bean.



                  > I'm pretty sure that this restriction is designed to
                  > discourage developers from implementing a waiting
                  > server thread that dispatches to worker threads,
                  > which the container's responsibility. Nevertheless,
                  > calling a cache that uses javagroups would clearly
                  > violate the literal meaning of these restrictions.
                  > Should I be concerned about accessing a TreeCache
                  > from within an EJB?

                  Well, first of all, there's a way in which TreeCache is going to be used in which you don't call the cache directly, but the (for example) PersistenceManager is going to do it for you (e.g. caching entity beans). This is in line with the J2EE philosophy where you define *what* you want, but not *how* you want to do it.

                  Secondly, as we provide the TreeCache as an MBean, you may or may not access it directly. But then again, this is a JBoss-proprietary interface, you make yourself dependent on this. This is the same as if an entity bean depends on any other MBean that makes up part of JBoss's functionality. I'm not saying this is bad, but you need to be aware of this.

                  That said, I think we will see some standard cache interface some time in the future, probably in the form of JCache, maybe even be part of the J2EE spec.

                  Bela


                  • 6. Re: Using jboss-cache outside of JBoss
                    magellan94

                    > Please note that this is 'fresh' code,

                    Thank you for the warning. I realize it's a work in progress, and I'm monitoring changes with daily updates from CVS. Fresh or not, it smells better than a blank source file in my IDE. If it proves too unstable, I may resort to a commercial product. I'd rather avoid that expense.
                    >
                    > > However, I'm concerned about the way JavaGroups
                    > creates threads
                    > > and network sockets to handle each layer of the
                    > protocol stack.
                    >
                    > Don't be ! You can remove a large number of threads
                    > used by JavaGroups by simply giving it a different
                    > configuration, this is totally deployment dependent.
                    > If you want to go crazy you can disable almost all
                    > threads, but at the expense of concurrency.

                    Ah, I see. I was able to disable the up & down handler threads for most protocols. Using FD instead of FD_SOCK saves me a server socket, and using the JMS protocol instead of UDP turns over a lot of network management to the container, where it belongs. Let me know if I'm on the wrong track here.

                    > > The EJB 2.0 specification imposes a few
                    > restrictions
                    > > on the code used by EJBs. Two of these
                    > restrictions
                    > > involve threading and network connections.
                    >
                    > Yes, that's true for beans. However, the TreeCache is
                    > part of the JBoss server

                    I think I was unclear... Although TreeCache is part of the jboss framework and not an EJB, my original question asks how to use the cache in a non-jboss application server. To invoke the cache *from* an EJB the cache must obey the programming restrictions in the EJB specification. I didn't mean to imply that the cache itself would be an EJB.

                    > This is in line with the J2EE philosophy where you
                    > define *what* you want, but not *how* you want to do
                    > it.

                    Unfortunately, J2EE makes it hard to add infrastructure to provide functionality not afforded by the spec. If only we could convince everyone to use jboss... The "what" that I want is high-performance access to value objects (transfer objects? pick your favorite pattern name du jour) from both EJBs in the application server and servlets in the web container. Caching seems like just the thing.

                    > That said, I think we will see some standard cache
                    > interface some time in the future, probably in the
                    > form of JCache, maybe even be part of the J2EE spec.

                    I hope you're right. I checkup on the jcache spec periodically, but there hasn't been much public activity for the last year or so. I hope they release a draft of the spec soon.

                    In the meantime, I think I can deploy jboss-cache in a servlet on WebLogic. This way, all the thread creation occurs in a web container, where it's legal. Subsequent access to the cache by an EJB doesn't create threads or server sockets, so I don't think I'll have any conflicts with the container. Although this feels like a misappropriation of the servlet spec, it'll save me a lot of work at the expense of a little elegance. When the application is ported to Jboss 4, of course, things will be much less clumsy.

                    Thanks, Dave

                    • 7. Re: Using jboss-cache outside of JBoss

                      Will the JBOSS cache developers get rid of the dependencies on JBOSS APP server libs on future version?

                      I know the dependency on JGROUPS.jar is required. Neverthleless - there shouldn't be a reason for developers to include all the JAR dependency package..

                      Why can't it be more like tangosol coherence? only two jar files are required - tangosol.jar and coherence.jar and nothing else.

                      • 8. Re: Using jboss-cache outside of JBoss
                        belaban

                         

                        "gdaswani" wrote:
                        Will the JBOSS cache developers get rid of the dependencies on JBOSS APP server libs on future version?


                        If you don't use TreeCacheAop, simply remove qdox.jar, jboss-aop.jar and javassist.jar

                        Otherwise, we're trying to gradually reduce the dependencies to jboss-xxx.jar files, off of the top of my mind, we currently depend mainly on JBoss' JMX impl, NestedExceptions and some other minor stuff.
                        We have a JIRA task open that will remove as much as possible from these dependencies, and club the remaining deps together in 1 JAR.


                        I know the dependency on JGROUPS.jar is required. Neverthleless - there shouldn't be a reason for developers to include all the JAR dependency package..


                        agreed


                        Why can't it be more like tangosol coherence?


                        You mean you want us to start charging you for the code ? :-)


                        only two jar files are required - tangosol.jar and coherence.jar and nothing else.


                        Don't know Coherence too well, maybe they offer less functionality ? Afaik, they don't have support for POJO replication.
                        For example, if they want to support JTA transactions, they'll need the javax.transaction.* package, which is part of J2EE. Maybe they clubbed all of the J2EE classes into 1 JAR.

                        • 9. Re: Using jboss-cache outside of JBoss

                           

                          "bela@jboss.com" wrote:

                          If you don't use TreeCacheAop, simply remove qdox.jar, jboss-aop.jar and javassist.jar

                          Otherwise, we're trying to gradually reduce the dependencies to jboss-xxx.jar files, off of the top of my mind, we currently depend mainly on JBoss' JMX impl, NestedExceptions and some other minor stuff.
                          We have a JIRA task open that will remove as much as possible from these dependencies, and club the remaining deps together in 1 JAR.


                          That's great. The first time I installed JBOSS-CACHE saw the list of JARS and was asking WTF. Thank god..


                          You mean you want us to start charging you for the code ? :-)


                          Yes, it does cost an arm and a leg - neverthless a darned good product. Something I'd rather pay for than let's say - IBM Websphere..


                          Don't know Coherence too well, maybe they offer less functionality ? Afaik, they don't have support for POJO replication.
                          For example, if they want to support JTA transactions, they'll need the javax.transaction.* package, which is part of J2EE. Maybe they clubbed all of the J2EE classes into 1 JAR.


                          Coherence supports POJO replication across the cluster - be it the simpler replicated cache offered by JBOSS-CACHE, to the more elaborate partitioned caches including near cache's which can then be backed by a distributed cache (somewhat similar to a CPU's L1 and L2 caches). If you guys had a roadmap on features to implement, I'd say - take a look at what caching strategies tangosol offers. Plus cluster wide locking..

                          In regards to the JTA support, and JCA - I believe they are seperated out onto different JAR files - nevertheless, if the feature isn't needed - there's no reason to require it as a concrete dependency..

                          Sounds like i'm plugging Coherence - not really :) I just like the product and I hope Jboss-Cache will be further enhanced to support it's elaborate caching strategies along with support for a distributed lock manager (coherent distributed cache).





                          • 10. Re: Using jboss-cache outside of JBoss
                            belaban

                             

                            "gdaswani" wrote:

                            Coherence supports POJO replication across the cluster


                            What I referred to is replication at the field level, e.g.

                            person.age++ would replicate only the "age" field, never the entire object. JBossCacheAOP does this.


                            to the more elaborate partitioned caches including near cache's which can then be backed by a distributed cache (somewhat similar to a CPU's L1 and L2 caches). If you guys had a roadmap on features to implement, I'd say - take a look at what caching strategies tangosol offers. Plus cluster wide locking.


                            We have remote caching on the roadmap (delegating CacheLoader), it is already partly implemented (but not advertized because it hasn't been tested yet).

                            What's the use case for cluster-wide locking ?
                            JGroups itself has a distributed lock manager, but I haven't seen a use case for it in JBossCache.


                            In regards to the JTA support, and JCA - I believe they are seperated out onto different JAR files - nevertheless, if the feature isn't needed - there's no reason to require it as a concrete dependency..


                            I hear you. I fully agree, too. But you have to understand that we have just ripped out the JBossCache (CVS) module from JBossAS, and JBossCache 1.2.3 is the first standalone version. In the versions to come, we will gradually remove more and more dependencies.
                            Promise.


                            I just like the product and I hope Jboss-Cache will be further enhanced to support it's elaborate caching strategies along with support for a distributed lock manager (coherent distributed cache).


                            We will get there eventually. Yes, we will take a look at the competition at some point, to see whether we offer the same functionality and - if not - see whether it makes sense to implement it.
                            Hope this helps,