Session timeout configuration
by Julien Viet
Hi,
I've been looking a bit at the Tomcat default configuration (the context.xml) and improved id : https://jira.jboss.org/browse/GTNPORTAL-1688
I was looking also at web.xml and a few war files have a session timeout value that is 30 minutes (portal.war and a 2 others).
This value matches the default tomcat and jboss value declared in the default.xml.
I would like to remove the value in web.xml because
1/ the change has no effect on the current configuration
2/ it simplifies the timeout configuration of those when touching the value that is set in the default web.xml
When one portal access is done, not only the portal war file has sessions created by usually also the portlets that the portal access: an anonymous hit on the default page creates 3 sessions in 3 war files. This change would per 2/ allow to have change it by changing the default value.
Also having a web.xml timeout different than the portal one does not make much sense as the war files are accessed by a request dispatch from the portal war. So any war file accessed this way will have its session bound to the portal one. A greater value does not have sense, a lower value can have sense but usually one would do that by specifying that value directly in the web.xml of the portlet application war file, so his configuration would not be much affected.
Then is a setting for a particular war file is needed, one can still make the setup in any web.xml he wants.
let me know if that makes sense to you
Julien
14 years, 10 months
Re: [gatein-dev] Session timeout configuration
by Prabhat Jha
Yes, that's true. I finally found the old email thread. I don't remember how it started ..probably related to a support case:
Steps to reproduce:
1) Start two instances of EPP5 in cluster
2) Start Apache with mod_jk as loadbalancer with sticky session enabled
3) Login as root in loadbalancer and going to
http://loadbalancer/portal/private/FailoverPortal/organization/management .
Actually I am seeing list of users in User management
4) Click to Group management
5) Failover active node which served requests from loadbalancer
6) Click to group "Platform" in group list menu. Now I expected to see
the "Platform" group details and it's subgroups. But I am redirected
back to "User management" and I am seeing list of users. So Organization
portlet is in default state and his actual UI state is lost.
And when <distributable /> in exoadmin.war is enabled, then behaviour is
correct and I am seeing details of "Platform" group in group management
menu. And I am not redirected to "User management".
I think there is more similar scenarios with <distributable /> in
exoadmin.war disabled. Problem is that state of WebUI administration
portlets, changed by ajax requests, is lost after failover and so these
admin portlets are always in default state after doing failover.
----- "Julien Viet" <julien(a)julienviet.com> wrote:
> but exoadmin is always accessed through the portal context, right ?
>
>
>
On Nov 24, 2010, at 10:53 PM, Prabhat Jha wrote:
>
> By default, distributable for exoadmin.war and other compressed .war files is not set but it is set for 02portal.war. For portal admin UI to work properly in cluster, it had to be enabled for exoadmin.war
>
> ----- "Julien Viet" < julien(a)julienviet.com > wrote:
> > can you clarify :-) ?
> >
On Nov 24, 2010, at 10:25 PM, Prabhat Jha wrote:
> > While we are on this topic, I think we should also clarify on <distributable/> configuration . I would have to dig previous mail threads but I think it needed changing in three .war for everything to work well in cluster.
> >
> >
> > ----- "Thomas Heute" < theute(a)redhat.com > wrote:
> > > I also agree
> > >
> > > On 11/24/2010 04:16 PM, Nicolas Filotto wrote:
Fully agree with you
> > >
> > >
> > > On Wed, Nov 24, 2010 at 3:05 PM, Julien Viet < julien(a)julienviet.com > wrote:
> > >
Hi,
> > >
> > > I've been looking a bit at the Tomcat default configuration (the context.xml) and improved id : https://jira.jboss.org/browse/GTNPORTAL-1688
> > >
> > > I was looking also at web.xml and a few war files have a session timeout value that is 30 minutes (portal.war and a 2 others).
> > >
> > > This value matches the default tomcat and jboss value declared in the default.xml.
> > >
> > > I would like to remove the value in web.xml because
> > >
> > > 1/ the change has no effect on the current configuration
> > > 2/ it simplifies the timeout configuration of those when touching the value that is set in the default web.xml
> > >
> > > When one portal access is done, not only the portal war file has sessions created by usually also the portlets that the portal access: an anonymous hit on the default page creates 3 sessions in 3 war files. This change would per 2/ allow to have change it by changing the default value.
> > >
> > > Also having a web.xml timeout different than the portal one does not make much sense as the war files are accessed by a request dispatch from the portal war. So any war file accessed this way will have its session bound to the portal one. A greater value does not have sense, a lower value can have sense but usually one would do that by specifying that value directly in the web.xml of the portlet application war file, so his configuration would not be much affected.
> > >
> > > Then is a setting for a particular war file is needed, one can still make the setup in any web.xml he wants.
> > >
> > > let me know if that makes sense to you
> > >
> > > Julien
> > > _______________________________________________
> > > gatein-dev mailing list
> > > gatein-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/gatein-dev
> > >
> > >
> > > --
> > > Nicolas Filotto
> > > Project Leader JCR
> > > eXo Platform SAS
> > > nicolas.filotto(a)exoplatform.com
> > > +33 (0)6 31 32 92 19
> > > _______________________________________________
gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev
> > >
> > > _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev _______________________________________________
> > gatein-dev mailing list
> > gatein-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/gatein-dev
> >
> >
>
14 years, 10 months
Re: [gatein-dev] Session timeout configuration
by Prabhat Jha
By default, distributable for exoadmin.war and other compressed .war files is not set but it is set for 02portal.war. For portal admin UI to work properly in cluster, it had to be enabled for exoadmin.war
----- "Julien Viet" <julien(a)julienviet.com> wrote:
> can you clarify :-) ?
>
On Nov 24, 2010, at 10:25 PM, Prabhat Jha wrote:
> While we are on this topic, I think we should also clarify on <distributable/> configuration . I would have to dig previous mail threads but I think it needed changing in three .war for everything to work well in cluster.
>
>
> ----- "Thomas Heute" < theute(a)redhat.com > wrote:
> > I also agree
> >
> > On 11/24/2010 04:16 PM, Nicolas Filotto wrote:
Fully agree with you
> >
> >
> > On Wed, Nov 24, 2010 at 3:05 PM, Julien Viet < julien(a)julienviet.com > wrote:
> >
Hi,
> >
> > I've been looking a bit at the Tomcat default configuration (the context.xml) and improved id : https://jira.jboss.org/browse/GTNPORTAL-1688
> >
> > I was looking also at web.xml and a few war files have a session timeout value that is 30 minutes (portal.war and a 2 others).
> >
> > This value matches the default tomcat and jboss value declared in the default.xml.
> >
> > I would like to remove the value in web.xml because
> >
> > 1/ the change has no effect on the current configuration
> > 2/ it simplifies the timeout configuration of those when touching the value that is set in the default web.xml
> >
> > When one portal access is done, not only the portal war file has sessions created by usually also the portlets that the portal access: an anonymous hit on the default page creates 3 sessions in 3 war files. This change would per 2/ allow to have change it by changing the default value.
> >
> > Also having a web.xml timeout different than the portal one does not make much sense as the war files are accessed by a request dispatch from the portal war. So any war file accessed this way will have its session bound to the portal one. A greater value does not have sense, a lower value can have sense but usually one would do that by specifying that value directly in the web.xml of the portlet application war file, so his configuration would not be much affected.
> >
> > Then is a setting for a particular war file is needed, one can still make the setup in any web.xml he wants.
> >
> > let me know if that makes sense to you
> >
> > Julien
> > _______________________________________________
> > gatein-dev mailing list
> > gatein-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/gatein-dev
> >
> >
> > --
> > Nicolas Filotto
> > Project Leader JCR
> > eXo Platform SAS
> > nicolas.filotto(a)exoplatform.com
> > +33 (0)6 31 32 92 19
> > _______________________________________________
gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev
> >
> > _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev _______________________________________________
> gatein-dev mailing list
> gatein-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/gatein-dev
>
>
14 years, 10 months
Packaging broken in trunk
by Marko Strukelj
I've built GateIn with empty local repository, and packaging failed to find
dependencies.
I had to change the list of repositories to get it to work:
Index: pom.xml
===================================================================
--- pom.xml (revision 4988)
+++ pom.xml (working copy)
@@ -190,7 +190,7 @@
<argument>-Dexo.working.dir=${gatein.working.dir}</argument>
<!--argument>-Dexo.src.dir=NONE</argument-->
<argument>-Dexo.dep.dir=${exo.projects.directory.dependencies}</argument><!--
to get the server ref install -->
-
<argument>-Dexo.m2.repos=file:${settings.localRepository},
http://maven2.exoplatform.org/rest/maven2,http://repository.jboss.org/maven2
</argument>
+
<argument>-Dexo.m2.repos=file:${settings.localRepository},
http://repository.exoplatform.org/content/groups/public,https://repositor...
</argument>
<argument>-Dclean.server=${exo.projects.app.jboss.version}</argument>
<argument>-Dexo.m2.home=${maven.home}</argument>
<argument>-Xms128m</argument>
@@ -390,7 +390,7 @@
<argument>-Dexo.working.dir=${gatein.working.dir}</argument>
<!--argument>-Dexo.src.dir=NONE</argument-->
<argument>-Dexo.dep.dir=${exo.projects.directory.dependencies}</argument><!--
to get the server ref install -->
-
<argument>-Dexo.m2.repos=file:${settings.localRepository},
http://maven2.exoplatform.org/rest/maven2,http://repository.jboss.org/maven2
</argument>
+
<argument>-Dexo.m2.repos=file:${settings.localRepository},
http://repository.exoplatform.org/content/groups/public,https://repositor...
</argument>
<argument>-Dclean.server=${exo.projects.app.jboss.version}</argument>
<argument>-Dexo.m2.home=${maven.home}</argument>
<argument>-Xms128m</argument>
14 years, 10 months
JCR ConcurrentModificationExceptions with WSRP
by Matt Wringe
Hi,
We are seeing occasional ConcurrentModificationException when accessing
certain portlets over wsrp. We already have a jira opened for this
https://jira.jboss.org/browse/GTNWSRP-84
The strange thing is that we have only been able to reproduce it on
linux machines, it doesn't appear to be reproducible on mac machines.
Has anyone seen issues like this before with respect to the jcr and
concurrent modifications? Or a jcr expert have a better idea to what the
issue is?
It looks like the wsrp jcr layer needs a bit of work to make it more
thread safe.
> Caused by: java.util.ConcurrentModificationException
> at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
> at java.util.AbstractList$Itr.next(AbstractList.java:343)
> at org.exoplatform.services.jcr.impl.core.SessionDataManager.validate(SessionDataManager.java:1421)
> at org.exoplatform.services.jcr.impl.core.SessionDataManager.commit(SessionDataManager.java:1332)
> at org.exoplatform.services.jcr.impl.core.ItemImpl.save(ItemImpl.java:681)
> at org.exoplatform.services.jcr.impl.core.SessionImpl.save(SessionImpl.java:935)
> at org.gatein.portal.wsrp.state.JCRPersister$WSRPSessionLifeCycle.save(JCRPersister.java:191)
> at org.chromattic.core.jcr.SessionWrapperImpl.save(SessionWrapperImpl.java:263)
> at org.chromattic.core.DomainSessionImpl._save(DomainSessionImpl.java:583)
> at org.chromattic.core.DomainSession.save(DomainSession.java:146)
> at org.chromattic.core.api.ChromatticSessionImpl.save(ChromatticSessionImpl.java:223)
> at org.gatein.portal.wsrp.state.JCRPersister.closeSession(JCRPersister.java:111)
> at org.gatein.portal.wsrp.state.consumer.JCRConsumerRegistry.update(JCRConsumerRegistry.java:116)
> at org.gatein.wsrp.consumer.registry.AbstractConsumerRegistry.updateProducerInfo(AbstractConsumerRegistry.java:249)
14 years, 11 months
user profile handler implementation
by Julien Viet
Hi Bolek,
I think today there is a missing feature in user profile handler implementation that is reflected by this thread http://community.jboss.org/thread/157717 and this JIRA https://jira.jboss.org/browse/GTNPORTAL-1567 .
I tried myself and also wrote this query for MySQL:
select c.id,c.name,a.name,b.attr_value from jbid_io_attr a, jbid_io_attr_text_values b, jbid_io c where a.attribute_id=b.text_attr_value_id and c.id=a.identity_object_id and c.name='john'
and it returns this table
I see in the code that the user profile handler makes a raw storage of the JSR 286 attributes in the database and I think that they should be mappable to specific attributes. At least we should be consistent and map firstName to user.name.given and lastName to user.name.family.
what do you think ?
14 years, 11 months
Update behaviour of PageNavigation.merge
by Matt Wringe
Currently when we are using the extension mechanism, we do not properly
merge the child PageNodes. What happens if that if the child PageNode
already exists it will overwrite the old PageNode with the new one.
Since PageNodes also has children PageNodes we are stuck in a situation
where we can only handle the top level of PageNodes tree. We cannot
currently use the extension mechanism to add a new page node anywhere in
the page node tree.
Jira with patch which merges the child nodes together:
https://jira.jboss.org/browse/GTNPORTAL-1605
I would have committed this, but it does change the behaviour of how
this works. Ie if someone was using the extension mechanism to overwrite
an existing page node.
Is anyone using it in this manner? Do we need to add an extra option to
pageNavigation which will tell it overwrite or not overwrite when
merging?
14 years, 11 months
