May 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-8043) Push JBossCacheManager loadSession logic into the ha-server-cache-spi impl

by Brian Stansberry (JIRA)

Push JBossCacheManager loadSession logic into the ha-server-cache-spi impl -------------------------------------------------------------------------- Key: JBAS-8043 URL: https://jira.jboss.org/browse/JBAS-8043 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 6.0.0.M4 JBCM loadSession() has a fair bit of complexity related to: 1) Managing a JBC batch 2) Ensuring the correct TCCL is in place. Once JBCLUSTER-272 is ready, eliminate 1). The ha-server-cache-spi impl already handles 2) correctly, so it can be removed. This will be helpful for JBAS-7852, as for that some of the loadSession logic will probably end up being duplicated in ClusteredSession. So simplifying it as much as possible is desirable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-272) Handling batching in AbstractJBossCacheServer.getSessionData

by Brian Stansberry (JIRA)

Handling batching in AbstractJBossCacheServer.getSessionData ------------------------------------------------------------ Key: JBCLUSTER-272 URL: https://jira.jboss.org/browse/JBCLUSTER-272 Project: JBoss Clustering Issue Type: Task Security Level: Public (Everyone can see) Components: HA-Server-Cache-JBC Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: HA-Server-Cache-JBC 2.2.2.Final The AS's JBossCacheManager.loadSession method has some fairly complex logic related to ensure a JBC batch is in progress and rolling it back or committing it if appropriate. This should be handled in AbstractJBossCacheService. This will be helpful for JBAS-7852, as for that some of the loadSession logic will probably end up being duplicated in ClusteredSession. So simplifying it as much as possible is desirable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-8002) Initial passivation of sessions during startup not based on full set of sessions

by Brian Stansberry (JIRA)

Initial passivation of sessions during startup not based on full set of sessions -------------------------------------------------------------------------------- Key: JBAS-8002 URL: https://jira.jboss.org/jira/browse/JBAS-8002 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Affects Versions: 6.0.0.M3, JBossAS-5.1.0.GA Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor Fix For: 6.0.0.CR1 JBossCacheManager.initializeUnloadedSessions() creates a map of sessions stored in the cache, key = session id, value = some metadata about the session. As it does this, it, passivates sessions if: 1) the last access time for the session > passivationMaxIdleTime_ 2) OR, # of sessions > maxActiveAllowed_ && last access time for the session > passivationMaxIdleTime_ Problem is 2) can only work correctly if # of session is the *full* count of sessions, not just the count so far through the loop. Otherwise you can have more sessions than you want, but the loop doesn't get to the point where it recognizes that until after sessions whose last access time for the session > passivationMaxIdleTime_ have been processed. Those sessions won't get passivated, and will end up remaining in memory. Effect: after the webapp is started, more sessions are in memory than intended, until the first run of the background processing thread at which point they will be passivated. Fix is to store all sessions in the unloadedSessions_ map, and then do a second loop for the passivation part. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-7850) Decouple distributed locking code from HAPartition

by Brian Stansberry (JIRA)

Decouple distributed locking code from HAPartition -------------------------------------------------- Key: JBAS-7850 URL: https://jira.jboss.org/jira/browse/JBAS-7850 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Fix For: JBossAS-6.0.0.M4 org.jboss.ha.framework.server.lock.AbstractClusterLockSupport is too tied to HAPartition. It needs access to: 1) A generic RPC invocation mechanism 2) Membership change notifications. Those could be implemented via a full HAPartition impl, via hacks on top of Infinispan, via direct use of RpcDispatcher, etc. So don't require the full HAPartition API. Probably the thing to do is have HAPartition itself become a composition of other, more focused interfaces. These would mean a change in ha-server-api project. Then AbstractClusterLockSupport could consume the relevant sub-interfaces. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
3
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-139) Create a general purpose group RPC API

by Brian Stansberry (JIRA)

Create a general purpose group RPC API -------------------------------------- Key: JBCLUSTER-139 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-139 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Q3Y6 Abstraction on top of JGroups RpcDispatcher. Start with HAPartition as a base, but minus DRM and DS. Consider what Messaging has done as well as JBCACHE-311. Consider separating the group membership API from the RPC API. RPC API would probably be a subinterface of the group membership one, as group RPC implies being aware of who the group is. This is lower priority, as, except for AS, its an internal implementation detail that can be changed. But, AS exposes HAPartition as an API for end-user code. -- 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

14 years, 1 month

2
8
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-223) Support for distributed locking

by Brian Stansberry (JIRA)

Support for distributed locking ------------------------------- Key: JBCLUSTER-223 URL: https://jira.jboss.org/jira/browse/JBCLUSTER-223 Project: JBoss Clustering Issue Type: Feature Request Security Level: Public (Everyone can see) Components: HA-Server-API Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: HA-Server-API 1.2.0.GA Useful for clustered DeploymentRepository and for ensuring only one node accesses a web session or SFSB at a time. This will be different from the JGroups DistributedLockManager is two main respects: 1) Built on HAPartition instead of RpcDispatcher. This is actually a negative, but I want this to be able to use the same channel the AS's HAPartition uses. Perhaps I'll develop a separate API and an adapter implementation that directly uses RpcDispatcher to provide flexibility going forward. 2) Acquiring a lock requires a callout to a pluggable LocalLockHandler. This is to support more sophisticated interaction with the service using the lock manager. I probably won't use the two-phase approach the JGroups DistributedLockManager adopts either. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
5
0 / 0

[JBoss JIRA] Created: (JBAS-7851) Distributed locking API should indicate whether taking lock from another node was necessary

by Brian Stansberry (JIRA)

Distributed locking API should indicate whether taking lock from another node was necessary ------------------------------------------------------------------------------------------- Key: JBAS-7851 URL: https://jira.jboss.org/jira/browse/JBAS-7851 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Fix For: JBossAS-6.0.0.M4 Callers asking for a lock should be able to distinguish these cases: 1) Lock can't be obtained 2) Lock obtained, and node already held it. 3) Lock obtained, but the node had to make a group RPC to get it Related to this, the API should also support creation of a new lock category such that the node immediately owns the lock with no group RPC. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
4
0 / 0

[JBoss JIRA] Created: (JBBUILD-618) Nexus developer users should only have access to promote their own staging repos

by Paul Gier (JIRA)

Nexus developer users should only have access to promote their own staging repos -------------------------------------------------------------------------------- Key: JBBUILD-618 URL: https://jira.jboss.org/browse/JBBUILD-618 Project: JBoss Build System Issue Type: Task Components: Artifact Repositories Reporter: Paul Gier Assignee: Paul Gier Fix For: Repository Support 2010 It seems that users with access to the staging repositories have permissions to close/drop/promote any staging repo, including those of other users. We should check with sonatype if there is a way to set the security so that users can only modify their own staging repos. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2071) Temporarily add JBOSS_HOME/lib/jboss-system.jar to the testsuite client classpath

by jaikiran pai (JIRA)

Temporarily add JBOSS_HOME/lib/jboss-system.jar to the testsuite client classpath --------------------------------------------------------------------------------- Key: EJBTHREE-2071 URL: https://jira.jboss.org/jira/browse/EJBTHREE-2071 Project: EJB 3.0 Issue Type: Task Components: testsuite Reporter: jaikiran pai Assignee: jaikiran pai Almost all tests in the testsuite are failing because of a recent change in AS trunk https://jira.jboss.org/jira/browse/JBAS-7818?focusedCommentId=12523915#ac... To get a sensible testsuite run, *temporarily* add JBOSS_HOME/lib/jboss-system.jar to the testsuite client classpath. Once the underlying issue in AS is fixed, revert this change in classpath. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

2
1
0 / 0

[JBoss JIRA] Created: (JBJPA-21) Extract VFS usage from deployers

by John Bailey (JIRA)

Extract VFS usage from deployers -------------------------------- Key: JBJPA-21 URL: https://jira.jboss.org/jira/browse/JBJPA-21 Project: JBoss JPA Issue Type: Feature Request Components: deployers Reporter: John Bailey Assignee: John Bailey Create an abstraction layer so the production code for jpa-deployers does not have any direct references on VFS -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2010