August 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCLUSTER-237) Improve ClusterChooserInterceptor exception messages

by Brian Stansberry (JIRA)

Improve ClusterChooserInterceptor exception messages ---------------------------------------------------- Key: JBCLUSTER-237 URL: https://jira.jboss.org/jira/browse/JBCLUSTER-237 Project: JBoss Clustering Issue Type: Task Security Level: Public (Everyone can see) Components: HA-Client Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor Fix For: HA-Client 2.0.0.BETA1 Stuff like the following needs improvement: target = (InvokerLocator) lb.chooseTarget(family.get()); if (target == null) { if (lastException != null) { throw new RuntimeException("cluster invocation failed, last exception was: ", lastException); } else { throw new RuntimeException("cluster invocation failed"); } } failoverCounter++; } // if we get here this means list was exhausted throw new RuntimeException("Unreachable?: Service unavailable."); -- 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

13 years, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-203) Genericize FamilyClusterInfo

by Brian Stansberry (JIRA)

Genericize FamilyClusterInfo ---------------------------- Key: JBCLUSTER-203 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-203 Project: JBoss Clustering Issue Type: Task Security Level: Public (Everyone can see) Components: HA-Client Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: 1.1.0.GA Mostly using List<Object> for the targets -- 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

13 years, 4 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-274) Lock ownership change notifications

by Brian Stansberry (JIRA)

Lock ownership change notifications ----------------------------------- Key: JBCLUSTER-274 URL: https://jira.jboss.org/browse/JBCLUSTER-274 Project: JBoss Clustering Issue Type: Feature Request Security Level: Public (Everyone can see) Components: HA-Server-API Reporter: Brian Stansberry Assignee: Brian Stansberry Add an ability to register for a notification when ownership of a particular lock changes. For example, with HttpSession clustering backed by JBC, we currently get callbacks when the cache changes, allowing us to know a local copy of a session is out of date with respect to the distributed cache. That won't work with DIST as the notification is not reliable. But another node taking ownership of the session will be noticed by the local lock manager, which could invoke a notification on the session manager. -- 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

13 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-276) More sophisticated state transfer handling

by Brian Stansberry (JIRA)

More sophisticated state transfer handling ------------------------------------------ Key: JBCLUSTER-276 URL: https://jira.jboss.org/browse/JBCLUSTER-276 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 2.0.0.Beta1 StateTransferProvider capable of returning a stream. GroupStateTransferService to expose getStateAsStream(). -- 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

13 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-281) Improve Channel management so HAPartition can integrate more easily

by Brian Stansberry (JIRA)

Improve Channel management so HAPartition can integrate more easily ------------------------------------------------------------------- Key: JBCLUSTER-281 URL: https://jira.jboss.org/browse/JBCLUSTER-281 Project: JBoss Clustering Issue Type: Feature Request Security Level: Public (Everyone can see) Components: HA-Server-Cache-JBC Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: HA-Server-Cache-JBC 2.4.0.Final The HAPartition in ha-server-core is based around the JGroups MuxRpcDispatcher and thus shares a ref to Channel with the cache instance used for DistributedState. Improve the integration to make it easier for HAPartition and the cache to coordinate getting a ref to and starting the channel. -- 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

13 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-204) Replication-based clustered Quartz job store

by Brian Stansberry (JIRA)

Replication-based clustered Quartz job store -------------------------------------------- Key: JBCLUSTER-204 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-204 Project: JBoss Clustering Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Backlog A Quartz job store impl that uses JBoss Cache or PojoCache to coordinate around the cluster instead of the db. -- 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

13 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-226) Make FamilyClusterInfoImpl internal members volatile

by Brian Stansberry (JIRA)

Make FamilyClusterInfoImpl internal members volatile ---------------------------------------------------- Key: JBCLUSTER-226 URL: https://jira.jboss.org/jira/browse/JBCLUSTER-226 Project: JBoss Clustering Issue Type: Bug Security Level: Public (Everyone can see) Components: HA-Client Affects Versions: HA-Client 1.1.1.GA Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: HA-Client 2.0.0.BETA1 At a minimum the "cursor" and "arbitraryObject" fields should be volatile. -- 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

13 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-240) Gravitated sessions still exposed to background cleanup

by Brian Stansberry (JIRA)

Gravitated sessions still exposed to background cleanup ------------------------------------------------------- Key: JBCLUSTER-240 URL: https://jira.jboss.org/jira/browse/JBCLUSTER-240 Project: JBoss Clustering Issue Type: Bug Security Level: Public (Everyone can see) Components: HA-Server-Cache-JBC Affects Versions: HA-Server-Cache-JBC 2.0.1.GA Reporter: Brian Stansberry Assignee: Brian Stansberry Follow up to JBCLUSTER-238. Still seeing an issue: [JBoss] 19:08:26,233 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (OOB-58,10.34.32.156:38607) Executing command: GravitateDataCommand{fqn=/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, searchSubtrees=true} [sender=10.34.32.154:46273] [JBoss] 19:08:26,234 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (OOB-58,10.34.32.156:38607) Command : GravitateDataCommand{fqn=/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, searchSubtrees=true} executed, result is: GravitateResult dataFound=true nodeData=[NodeData {fqn: /JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, attrs={0=3, 1=1250615302074, 2=org.jboss.web.tomcat.service.session.distributedcache.spi.DistributableSessionMetadata@30176a8f, 3=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw=nullserialized=true}}}] fqn=/_BUDDY_BACKUP_/10.34.32.153_2585/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__ [JBoss] 19:08:26,571 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (Incoming-15,10.34.32.156:38607) Executing command: DataGravitationCleanupCommand{fqn=/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, backup=/_BUDDY_BACKUP_/10.34.32.153_2585/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__} [sender=10.34.32.154:46273] [JBoss] 19:08:26,572 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (Incoming-15,10.34.32.156:38607) Command : DataGravitationCleanupCommand{fqn=/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, backup=/_BUDDY_BACKUP_/10.34.32.153_2585/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__} executed, result is: null [JBoss] 19:11:36,727 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (Incoming-7,10.34.32.156:38607) Executing command: DataGravitationCleanupCommand{fqn=/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, backup=/_BUDDY_BACKUP_/10.34.32.154_46273:DEAD/1/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__} [sender=10.34.32.155:60743] [JBoss] 19:11:36,728 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (Incoming-7,10.34.32.156:38607) Command : DataGravitationCleanupCommand{fqn=/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, backup=/_BUDDY_BACKUP_/10.34.32.154_46273:DEAD/1/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__} executed, result is: null [JBoss] 19:14:24,493 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) dests=null, command=GravitateDataCommand{fqn=/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, searchSubtrees=true}, mode=2, timeout=17500 [JBoss] 19:14:24,496 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) responses: [sender=10.34.32.153:47135, retval=GravitateResult dataFound=true nodeData=[NodeData {fqn: /JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, attrs={0=92, 1=1250615662411, 2=org.jboss.web.tomcat.service.session.distributedcache.spi.DistributableSessionMetadata@2e075959, 3=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw=nullserialized=true}}}] fqn=/_BUDDY_BACKUP_/10.34.32.155_60743/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, received=true, suspected=false] [JBoss] [sender=10.34.32.155:60743, retval=GravitateResult dataFound=true nodeData=[NodeData {fqn: /JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, attrs={0=92, 1=1250615662411, 2=org.jboss.web.tomcat.service.session.distributedcache.spi.DistributableSessionMetadata@647af9aa, 3=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw=nullserialized=true}}}] fqn=/_BUDDY_BACKUP_/10.34.32.155_60743/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, received=true, suspected=false] [JBoss] 19:14:24,497 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) dests=[10.34.32.155:60743], command=ReplicateCommand{cmds=PrepareCommand{globalTransaction=GlobalTransaction:<10.34.32.156:38607>:203, modifications=[PutDataMapCommand{fqn=/_BUDDY_BACKUP_/10.34.32.156_38607/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, dataVersion=null, data={0=92, 1=1250615662411, 2=org.jboss.web.tomcat.service.session.distributedcache.spi.DistributableSessionMetadata@2e075959, 3=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw={payLoad=org.jboss.test.cluster.servlet.SessionPayload@55a9181d}serialized=false}}, globalTransaction=null, erase=false}], localAddress=10.34.32.156:38607, onePhaseCommit=false}}, mode=2, timeout=17500 [JBoss] 19:14:24,499 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) dests=null, command=DataGravitationCleanupCommand{fqn=/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, backup=/_BUDDY_BACKUP_/10.34.32.155_60743/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__}, mode=6, timeout=-1 The background thread should not be interested in this session. -- 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

13 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-7272) Handle MergeViews in AbstractClusterLockSupport variants

by Brian Stansberry (JIRA)

Handle MergeViews in AbstractClusterLockSupport variants -------------------------------------------------------- Key: JBAS-7272 URL: https://jira.jboss.org/jira/browse/JBAS-7272 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.Alpha1 org.jboss.ha.framework.server.lock.AbstractClusterLockSupport and/or its subclasses need to deal with cluster merges, i.e. AS instances in groups {A, B} and {C, D} discover each other and form a single group {A, B, C, D}. Following a merge, it's possible a node in each of the merged subgroups thinks it has the cluster wide lock. A simple approach that *may* work in all cases is to handle a merge by having each node abandon the cluster-wide lock, forcing the next attempt by a local caller to re-acquire the lock. Need to think through though whether that is the correct semantic in all cases. AbstractClusterLockSupport needs to implement HAExtendedMembershipListener instead of just HAMembershipListener; this will allow it to know whether a view change was due to a merge. -- 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

13 years, 4 months

1
3
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-188) Possible further extraction of clustering code from AS codebase

by Brian Stansberry (JIRA)

Possible further extraction of clustering code from AS codebase --------------------------------------------------------------- Key: JBCLUSTER-188 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-188 Project: JBoss Clustering Issue Type: Task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Q3Y8 Container task for evaluating further extractions. -- 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

13 years, 4 months

1
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2010