September 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBCACHE-326) Create the concept of a "priority queue" to speed execution of certain remote method invocations

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-326?page=all ] Manik Surtani updated JBCACHE-326: ---------------------------------- Complexity: Medium Assignee: Vladimir Blagojevic (was: Bela Ban) Are we still doing this? This is the concept of a separate 'processor' thread for state events. > Create the concept of a "priority queue" to speed execution of certain remote method invocations > ------------------------------------------------------------------------------------------------ > > Key: JBCACHE-326 > URL: http://jira.jboss.com/jira/browse/JBCACHE-326 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Brian Stansberry > Assigned To: Vladimir Blagojevic > Fix For: 2.0.0 > > > Change the handling of requests in JBossCache (another interceptor on top of ReplicationInterceptor): > - Create 2 queues (of MethodCall objects), one thread for each queue > - The regular MethodCalls like put(), remove() etc go into the default queue (A), where they are processed according to order (FIFO) > - The special calls like block(), _getState(), commit() or acks for PREPARE/COMMIT calls go into the other (priority) queue (B), these calls *CAN* be received out of sequence > - This way, an _getState() would always be processed and would be able to (1) stop the processing of queue A and (2) force- release any locks held > by on the tree. > _ This way commit() calls can promptly release locks, without having to wait behind other prepare calls. -- 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

19 years, 8 months

1
0
0 / 0

[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.0.0 (was: 2.1.0) Affects: [Documentation (Ref Guide, User Guide, etc.)] Complexity: High Targetting this for 2.0.0 rather than 2.1.0 > 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.0.0 > > > 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

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3646) LdapExtLoginModule still has connection leak

by Scott M Stark (JIRA)

LdapExtLoginModule still has connection leak -------------------------------------------- Key: JBAS-3646 URL: http://jira.jboss.com/jira/browse/JBAS-3646 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Security Affects Versions: JBossAS-4.0.4.GA Reporter: Scott M Stark Assigned To: Scott M Stark Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well. -- 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

19 years, 8 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-3645) LdapExtLoginModule still has connection leak

by Scott M Stark (JIRA)

LdapExtLoginModule still has connection leak -------------------------------------------- Key: JBAS-3645 URL: http://jira.jboss.com/jira/browse/JBAS-3645 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Security Affects Versions: JBossAS-4.0.4.GA Reporter: Scott M Stark Assigned To: Scott M Stark Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well. -- 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

19 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-749) Make BdbjeCacheLoader use the standard format for persistent state transfer

by Brian Stansberry (JIRA)

Make BdbjeCacheLoader use the standard format for persistent state transfer --------------------------------------------------------------------------- Key: JBCACHE-749 URL: http://jira.jboss.com/jira/browse/JBCACHE-749 Project: JBoss Cache Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Cache loaders Reporter: Brian Stansberry The state should be a sequence of NodeData objects; see FileCacheLoader or JDBCCacheLoader. -- 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

19 years, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (SECURITY-4) Evaluate OpenDS (Sun's OSS all-java Directory Server)

by Anil Saldhana (JIRA)

Evaluate OpenDS (Sun's OSS all-java Directory Server) ----------------------------------------------------- Key: SECURITY-4 URL: http://jira.jboss.com/jira/browse/SECURITY-4 Project: JBoss Security Issue Type: Task Security Level: Public (Everyone can see) Components: JBossSX Reporter: Anil Saldhana Assigned To: Scott M Stark https://opends.dev.java.net/public/docs/OpenDS-FAQ.html - Requires JDK5. - Java only. - Ldif import/export supported. Good candidate for HEAD testsuite integration. -- 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

19 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1029) Ability for an administrator to add/remove users

by Morten Hauch (JIRA)

Ability for an administrator to add/remove users ------------------------------------------------ Key: JBPORTAL-1029 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1029 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal Portlet Reporter: Morten Hauch Assigned To: Julien Viet In the UserPortlet it should be possible to portal administrators to create new users and delete users. -- 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

19 years, 8 months

2
4
0 / 0

[JBoss JIRA] Updated: (JBCACHE-315) Break locks for state transfer

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-315?page=all ] Brian Stansberry updated JBCACHE-315: ------------------------------------- JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=76038 > 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.1.0 > > > 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

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBSEAM-262) Add another addFromResourceBundle method to class FacesMessages

by Richard Brooks (JIRA)

[ http://jira.jboss.com/jira/browse/JBSEAM-262?page=comments#action_12343198 ] Richard Brooks commented on JBSEAM-262: --------------------------------------- (already posted on forum see http://www.jboss.com/index.html?module=bb&op=viewtopic&t=90463) Looking at the diff it appears that the id parameter has been added to the method signatures but isn't passed through unless you use the method with all the parameters (severity, default, etc) (diff http://fisheye.jboss.org/viewrep/JBoss/jboss-seam/src/main/org/jboss/seam...) I haven't actually run the code as I only came across it trying to do the same thing in 1.0.1 GA so I could be mistaken > Add another addFromResourceBundle method to class FacesMessages > --------------------------------------------------------------- > > Key: JBSEAM-262 > URL: http://jira.jboss.com/jira/browse/JBSEAM-262 > Project: JBoss Seam > Issue Type: Feature Request > Components: JSF > Reporter: Bruce Raggett > Assigned To: Gavin King > Fix For: 1.1 > > > Is it possible to add another addFromResourceBundle method to class FacesMessages which would accept a JSF component id parameter? This enhancement would make it easy for a session bean to display a localized message from the resource bundle against a specific JSF input field. -- 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

19 years, 8 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-434) InternalDelegate doesn't relocate AOP nodes properly

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-434?page=all ] Ben Wang resolved JBCACHE-434. ------------------------------ Resolution: Out of Date Since PojoCache object mapping has been refactored in 2.0, this issue should not relevant anymore. > InternalDelegate doesn't relocate AOP nodes properly > ---------------------------------------------------- > > Key: JBCACHE-434 > URL: http://jira.jboss.com/jira/browse/JBCACHE-434 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 1.2.4SP1 > Reporter: twundke > Assigned To: Ben Wang > Fix For: 2.0.0 > > Attachments: relocate.txt > > > When the object graph handler attempts to remove a node that has references to it, it relocates the data to the first referencing FQN in the list. However, InternalDelegate.relocate() fails to correctly update the AOP references. There is some commented-out code that seems to attempt to update the indirect FQN. > I've attatched my updated code (for our demo), but it's overly complicated due to lack of time, sleep etc. In fact it fully updates the internal state of the cache for the node (including changing the indirect FQN, and changing all references to point to the new indirect FQN), which was the quickest way to get a solution at the time. You can probably cut out half of this by simply updating the indirect FQN correctly, which I presume was the intent in the first place. However, I believe this still only half-solves the problem as the reference counts need to be updated. > Sorry if this is a bit of a vague bug report Ben, but I can't fully remember my thinking at the time. Hopefully my code at least shows all that has to be done to keep the cache consistent. -- 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

19 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2006