[JBoss JIRA] Updated: (JBCACHE-315) Break locks for state transfer
by Manik Surtani (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-315?page=all ]
Manik Surtani updated JBCACHE-315:
----------------------------------
Fix Version/s: 2.2.0.GA
(was: 2.1.0.GA)
(was: 2.1.0.CR1)
Postponing pending virtual synchrony enhancements in JGroups 2.6
> Break locks for state transfer
> ------------------------------
>
> Key: JBCACHE-315
> URL: http://jira.jboss.com/jira/browse/JBCACHE-315
> Project: JBoss Cache
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assigned To: Vladimir Blagojevic
> Priority: Critical
> Fix For: 2.2.0.GA
>
>
> State transfer needs to acquire a lock on the root to make sure all existing TXs have been completed. However, when a TX takes more time than the lock acquisition timeout, state transfer will fail.
> Therefore, we need to forcefully acquire the locks for the state transfer by force-releasing the existing locks, and rolling back all TXs that held those locks.
> This will ensure that state transfer always succeeds, at the expense of some rolled back TXs.
> We need to investigate how this works with optimistic locking
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 11 months
[JBoss JIRA] Created: (JBPORTAL-1619) Multiple maximized windows
by Ovidiu Nichifor (JIRA)
Multiple maximized windows
--------------------------
Key: JBPORTAL-1619
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1619
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal Core
Affects Versions: 2.6 Final
Reporter: Ovidiu Nichifor
Assigned To: Julien Viet
Once you authenticate (admin/admin) you'll be brought to the default page of the user account. Suppose the default page contains the "Greetings" and "User" portlets. I have noticed something strange that i don't know if it is really a bug or a feature.
If you follow the next steps:
1. with your browser access: http://<hostname>:<port>/portal/auth/portal/default/default/JSPPortletWindow?windowstate=maximized
2. with your browser access: http://<hostname>:<port>/portal/auth/portal/default/default/UserPortletWindow?windowstate=maximized without normalize first the previous maximized window.
you'll have two windows that are both in the maximized state. Now, the portal should present to you the last maximized window.
If you try to normalize/minimize the maximized window, the portal will display the other maximized window instead of bringing you back to the page in the "normal" state (i.e. with all defined portlets on it).
Is this the way it should work? I've been digging in the JBoss Portal 2.6.ALPHA1 source code and i found a "ensureSingleMaximizedWindow" method in the "org.jboss.portal.theme.impl.strategy.MaximizingStrategyImpl" file that does nothing - only throws a FixMe exception. Both JBP-2.6.FINAL & JBP-2.6.ALPHA1 have the same behavior on the test case i described so i assume the maximizing strategy hasn't been changed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 11 months