May 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBVFS-136) Handle symlinks wrt vfs cache

by Ales Justin (JIRA)

Handle symlinks wrt vfs cache ----------------------------- Key: JBVFS-136 URL: https://jira.jboss.org/jira/browse/JBVFS-136 Project: JBoss VFS Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Alpha2 Reporter: Ales Justin Assignee: Ales Justin Fix For: 2.2.0.Alpha3 Symlinks are not properly handled in VFSRegistry wrt cached contexts. -- 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

16 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-8042) CLONE -Parse errors from JSF when initializing admin-console

by Shelly McGowan (JIRA)

CLONE -Parse errors from JSF when initializing admin-console ------------------------------------------------------------ Key: JBAS-8042 URL: https://jira.jboss.org/browse/JBAS-8042 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JSF Reporter: Shelly McGowan Assignee: Stan Silvert Priority: Critical Fix For: 6.0.0.M2 Attachments: jboss-jsfunit-examples-ajax4jsf.war Initializing he admin-console.war built using the latest EMBJOPR trunk (with workaround noted in EMBJOPR-269) fails due with parse errors from .xml file in jsf-impl.jar: 17:46:47,428 SEVERE [facelets.compiler] Error Loading Library: vfszip:/work/TRUNK/trunk/build/output/jboss-6.0.0-SNAPSHOT/server/all/deploy/jbossweb.sar/jsf-libs/jsf-impl.jar/com/sun/faces/metadata/taglib/composite.taglib.xml: java.io.IOException: Error parsing [vfszip:/work/TRUNK/trunk/build/output/jboss-6.0.0-SNAPSHOT/server/all/deploy/jbossweb.sar/jsf-libs/jsf-impl.jar/com/sun/faces/metadata/taglib/composite.taglib.xml]: at com.sun.facelets.compiler.TagLibraryConfig.create(TagLibraryConfig.java:410) Caused by: org.xml.sax.SAXException: Error Handling [vfszip:/work/TRUNK/trunk/build/output/jboss-6.0.0-SNAPSHOT/server/all/deploy/jbossweb.sar/jsf-libs/jsf-impl.jar/com/sun/faces/metadata/taglib/composite.taglib.xml@41,29] at com.sun.facelets.compiler.TagLibraryConfig$LibraryHandler.error(TagLibraryConfig.java:376) Full trace here: http://pastebin.com/m85eee91 -- 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

16 years, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBREM-1223) Release 2.5.2.SP3

by Ron Sigal (JIRA)

Release 2.5.2.SP3 ----------------- Key: JBREM-1223 URL: https://jira.jboss.org/jira/browse/JBREM-1223 Project: JBoss Remoting Issue Type: Release Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2.SP3 (Flounder) -- 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

16 years, 2 months

1
1
0 / 0

[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

16 years, 2 months

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

16 years, 2 months

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

16 years, 2 months

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

16 years, 2 months

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

16 years, 2 months

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

16 years, 2 months

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

16 years, 2 months

1
4
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 May 2010