[wildfly-dev] How to configure Wildfly to use the InMemorySessionManager instead of DistributableSessionManager?

Eric B ebenzacar at gmail.com
Wed Dec 20 22:32:07 EST 2017


The jboss-all.xml has the following content:

<jboss umlns="urn:jboss:1.0">
  <shared-session-config xmlns="urn:jboss:shared-session-config:1.0">
    <session-config>
      <session-timeout>30</session-timeout>
      <cookie-config>
        <name>JSESSIONID_NG</name>
        <path>/</path>
        <comment>cookie comment</comment>
        <max-age>-1</max-age>
      </cookie-config>
    </session-config>
  </shared-session-config>
</jboss>


Does that mean that it must use distributable session manager?   Or should
shared sessions like that still be able to work with the
InMemorySessionManager?  Of course, I realize that it would have to be the
same IMSM used in all apps.

If not I'll have to see if I can reproduce this with a POC rather than my
huge monolith.

Thanks,

Eric


On Wed, Dec 20, 2017 at 7:09 PM, Stuart Douglas <stuart.w.douglas at gmail.com>
wrote:

> It should be using this by default, unless the app is distributable. This
> sounds like a bug. Do you have a reproducer I can look at? All I can think
> of is that if you have a distributable web fragment in your app maybe we
> are merging them incorrectly.
>
> Stuart
>
> On Wed, Dec 20, 2017 at 11:07 PM, Eric B <ebenzacar at gmail.com> wrote:
>
>> I've changed the cookie path to / within the jboss-all.xml file in order
>> for two war to share the same session.  (Each war has its own context path:
>> /war1, /war).  I essentially need one war to be able to authenticate and
>> authorize the user, and have that authentication/authorization carry over
>> to the session in the other war.  I don't actually need to share the
>> session other than for auth purposes.
>>
>> Is that feasible using the InMemorySessionManager?  Is there a way to
>> ensure that they are all using the same InMemorySessionManager?
>>
>> Thanks
>>
>> Eric
>>
>> On Dec 20, 2017 1:10 AM, "Stuart Douglas" <stuart.w.douglas at gmail.com>
>> wrote:
>>
>>> Are you using the shared session functionality? Or just overriding the
>>> cookie path so the same cookie is used for two different session managers?
>>>
>>> Stuart
>>>
>>> On Wed, Dec 20, 2017 at 4:49 PM, Eric B <ebenzacar at gmail.com> wrote:
>>>
>>>> Hi Stuart,
>>>>
>>>> Strangely enough, my web.xml does not have distributable defined.
>>>>
>>>> I managed to get the InMemorySessionManager working by using a servlet
>>>> extension, but I can't help but think I'm using a sledge hammer to
>>>> configure it that way.  I can't believe there isn't another way to enable
>>>> non distributable sessions.
>>>>
>>>> My application is a JEE ear with 2 web apps (using a shared session
>>>> cookie) and an EJB package if that makes a difference.
>>>>
>>>> Thanks
>>>>
>>>> Eric
>>>>
>>>>
>>>> On Dec 19, 2017 5:44 PM, "Stuart Douglas" <stuart.w.douglas at gmail.com>
>>>> wrote:
>>>>
>>>> If you remove <distributable/> from your web.xml you should just get
>>>> the InMemorySessionManager.
>>>>
>>>> Stuart
>>>>
>>>> On Wed, Dec 20, 2017 at 4:29 AM, Eric B <ebenzacar at gmail.com> wrote:
>>>>
>>>>> I've continued digging into my issue and noticed that the default
>>>>> DistributableSessionManager uses the org.wildfly.clustering.web
>>>>> .infinispan.session.InfinispanSessionManager, which I guess comes
>>>>> from the module parameter in the cache-container definition.
>>>>>
>>>>> Part of my problem is that I am trying to invalidate() the session
>>>>> returned by the SessionManager, but when I do a
>>>>> SessionManager.getSession(sessionId), it returns an
>>>>> DistributableImmutableSession whose invalidate() method intentionally does
>>>>> nothing.
>>>>>
>>>>> So how can I invalidate a session?  Is there no way to invalidate a
>>>>> session by sessionId with the DistributableSessionManager?  If so, how?  If
>>>>> not, how do I define a SessionManager that would give me access that?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Eric
>>>>>
>>>>> On Tue, Dec 19, 2017 at 11:38 AM, Eric B <ebenzacar at gmail.com> wrote:
>>>>>
>>>>>> Further to a previous post for session problems in my application, I
>>>>>> believe some of my issues relate to the DistributableSessions that are
>>>>>> being used by Wildfly.  However, in my configuration file, I have my web
>>>>>> cache defined as a local cache:
>>>>>>
>>>>>>
>>>>>>
>>>>>>         <subsystem xmlns="urn:jboss:domain:infinispan:4.0">
>>>>>>             <cache-container name="server" aliases="singleton
>>>>>> cluster" default-cache="default" module="org.wildfly.clustering
>>>>>> .server">
>>>>>>                 <transport lock-timeout="60000"/>
>>>>>>                 <replicated-cache name="default" mode="SYNC">
>>>>>>                     <transaction mode="BATCH"/>
>>>>>>                 </replicated-cache>
>>>>>>             </cache-container>
>>>>>>             <cache-container name="web" default-cache="passivation"
>>>>>> module="org.wildfly.clustering.web.infinispan">
>>>>>>                 <local-cache name="passivation">
>>>>>>                     <locking isolation="REPEATABLE_READ"/>
>>>>>>                     <transaction mode="BATCH"/>
>>>>>>                     <file-store passivation="true" purge="false"/>
>>>>>>                 </local-cache>
>>>>>>                 <local-cache name="persistent">
>>>>>>                     <locking isolation="REPEATABLE_READ"/>
>>>>>>                     <transaction mode="BATCH"/>
>>>>>>                     <file-store passivation="false" purge="false"/>
>>>>>>                 </local-cache>
>>>>>>             </cache-container>
>>>>>> ...
>>>>>> ...
>>>>>>
>>>>>>
>>>>>> I see that undertow comes with an InMemorySessionManager, but not
>>>>>> entirely sure how to enable it.  Do I have to go through the effort of
>>>>>> creating my own ServletExtension and configuring it in the
>>>>>> META-INF/services/io.undertow.servlet.ServletExtension or is there
>>>>>> an out-of-the-box way of enable functionality that already exists via the
>>>>>> config file?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Eric
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>
>>>>
>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171220/d78139eb/attachment-0001.html 


More information about the wildfly-dev mailing list