Externalize HTTP Sessions to MongoDB on Wildfly 27

[Ronny Gunawan]

I'm trying to persist the session on wildfly into mongodb using following cache store: https://github.com/infinispan/infinispan-cachestore-mongodb.

Can someone guide me on how to configure it? 

I tried adding it into standalone.xml as per following but received error invalid persistence element or invalid mongodbStore element.

            <cache-container name="web" default-cache="passivation" marshaller="PROTOSTREAM" modules="org.wildfly.clustering.web.infinispan">

                <local-cache name="passivation">

                    <!-- <expiration interval="0"/>

                    <file-store passivation="false" purge="false"/> -->

                    <persistence passivation="false">

                        <mongodbStore xmlns="urn:infinispan:store:mongodb:9.4">

                            <connection

                                    uri="mongodb://user:password@localhost:27017/infinispan_test_database?w=0&amp;connectTimeoutMS=2000"

                                    collection="infinispan_cachestore"/>

                            <write-behind />

                        </mongodbStore>

                    </persistence>

                </local-cache>

                <local-cache name="sso">

                    <expiration interval="0"/>

                </local-cache>

            </cache-container>

[Paul Ferraro]

The infinispan subsystem does not contain native support for the mongodb cache store, nor does the subsystem parser support the use of store-specific configuration parsing via namespace.

You can, however, bundle the mongodb cache store as a module and configure a custom cache store that loads this store via its module.

e.g.

<cache-container name="web" marshaller="PROTOSTREAM" modules="org.wildfly.clustering.web.infinispan org.infinispan.persistence.mongodb">

    <!-- ... -->

    <custom-store passivation="false" class="org.infinispan.persistence.mongodb.configuration.MongoDBStoreConfigurationBuilder">

        <property name="foo">bar</property>

    </custom-store>

</cache-container>

This requires that the cache store implementation is able to configure itself via properties, so YMMV.

Other comments:

* Your configuration above suggests that you only intend to access sessions from a single WildFly instance - is that correct?

* MongoDB is an interesting choice for a local cache store.  It will almost certainly perform worse than the default file-store.

* By commenting out <expiration interval="0"/>, you have enabled an expiration reaper thread that will never be used.  Why?

[Ronny Gunawan]

Thanks a lot Paul for your reply. Let me give a try your suggestion. 

I appreciate your help a lot.

As for other comments:

* Your configuration above suggests that you only intend to access sessions from a single WildFly instance - is that correct?

  Yes, you're right

* MongoDB is an interesting choice for a local cache store.  It will almost certainly perform worse than the default file-store.

  Our objective is to centralized the session store while leveraging existing database which already in mongodb

* By commenting out <expiration interval="0"/>, you have enabled an expiration reaper thread that will never be used.  Why?

  It was disabled by mistake as I want to highlight the new changes I added to the configuration.xml, I will actually revert it after integrating the mongodb custom store

[Ronny Gunawan]

Hi Paul,

Appreciate your guidance and suggestion to use custom module + cache store with MongoDB and it does work for me after refactor the infinispan-cache-mongodb library to match with latest Infinispan 14 dependency library.

One question I have on NonBlockingStore<K, V>  interface, does it adopt a singleton pattern by default? Or is it something that we need to handle it?

Somehow seems there are multiple threads that writing session data to DB while I'm testing the change.

Thank you and regards,

Ronny

[Paul Ferraro]

On Wednesday, March 8, 2023 at 2:12:08 AM UTC-5 Ronny Gunawan wrote:

Hi Paul,

Appreciate your guidance and suggestion to use custom module + cache store with MongoDB and it does work for me after refactor the infinispan-cache-mongodb library to match with latest Infinispan 14 dependency library.

One question I have on NonBlockingStore<K, V>  interface, does it adopt a singleton pattern by default?

The NonBlockingStore<K, V> interface is implemented by every cache store.  Every cache instance configured with a cache store will create a separate cache store instance.

 

Or is it something that we need to handle it?

I'm not sure what you mean.

 

Somehow seems there are multiple threads that writing session data to DB while I'm testing the change.

Write behind cache store operations will always execute on a thread from Infinispan's non-blocking thread pool:

https://docs.wildfly.org/27/wildscribe/subsystem/infinispan/cache-container/thread-pool/non-blocking/index.html

Unless the cache store method implementation explicitly delegates to a blocking thread, in which case, it may also use threads from Infinispan's blocking thread pool:

https://docs.wildfly.org/27/wildscribe/subsystem/infinispan/cache-container/thread-pool/blocking/index.html

[Ronny Gunawan]

Hi Paul,

Somehow when I tried with a simple helloworld request and setting a value in the session, it will trigger multiple writes which may come for multiple threads.

Let me read on the reference article that you suggested.

Thanks again and regards,

Ronny

[Paul Ferraro]

On Thursday, March 9, 2023 at 9:29:20 PM UTC-5 Ronny Gunawan wrote:

Hi Paul,

Somehow when I tried with a simple helloworld request and setting a value in the session, it will trigger multiple writes which may come for multiple threads.

This is what I would expect, given your configuration above.

What exactly is your concern?

[Ronny Gunawan]

Hi Paul,

Thanks for your reply.  I found your explanation of different session keys and attributes stored in the DB. Hence, it explained why there are multiple documents in the DB.

I'm still testing the functionality and assess if the behavior looks fine with session store on mongdb. Kind of testing the flow on session expiry, distributed session, session failover, etc.

Thanks for all your help.

Best Regards,

Ronny