January 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-619) Change getState semantics

by Vladimir Blagojevic (JIRA)

Change getState semantics ------------------------- Key: JGRP-619 URL: http://jira.jboss.com/jira/browse/JGRP-619 Project: JGroups Issue Type: Task Affects Versions: 2.5, 2.4, 2.3, 2.2.9 Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic Fix For: 3.0 Currently Channel's getState method returns boolean indicating only whether state was successfully received by state receiver and not whether it was successfully processed at relevant channel listener. This anomaly lead convoluted application code that had to do rather complicated lock synchronization and notification mechanism on the progress of entire state transfer. We have to simplify this process! State receiver should simply call blocking getState and be notified in the form of Exception of anything that went wrong; be it that state could not be received at all or that it was received but could not be installed at channel listener. This issue is closely related to revamping of channel state transfer callbacks - JGRP-563 -- 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

12 years, 11 months

2
8
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1026) Refactor extended persistence context

by Carlo de Wolf (JIRA)

Refactor extended persistence context ------------------------------------- Key: EJBTHREE-1026 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1026 Project: EJB 3.0 Issue Type: Task Reporter: Carlo de Wolf Assigned To: Carlo de Wolf Fix For: EJB 3.0 RC11 - FD -- 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

12 years, 12 months

3
19
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-229) Comparison of String objects using == in FamilyClusterInfoImpl.equals(Object)

by Brian Stansberry (JIRA)

Comparison of String objects using == in FamilyClusterInfoImpl.equals(Object) ------------------------------------------------------------------------------ Key: JBCLUSTER-229 URL: https://jira.jboss.org/jira/browse/JBCLUSTER-229 Project: JBoss Clustering Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor Fix For: HA-Client 2.0.0.BETA1 return fr.familyName == this.familyName; Minor issue as this is semi-valid since the familyName field comes via ClusteringTargetsRepository, which ensures only a single String gets passed. -- 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

12 years, 12 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-231) ClusteringTargetsRepository.families isn't final but should be

by Brian Stansberry (JIRA)

ClusteringTargetsRepository.families isn't final but should be -------------------------------------------------------------- Key: JBCLUSTER-231 URL: https://jira.jboss.org/jira/browse/JBCLUSTER-231 Project: JBoss Clustering Issue Type: Task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor Fix For: HA-Client 2.0.0.BETA1 -- 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

12 years, 12 months

1
1
0 / 0

[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

12 years, 12 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

12 years, 12 months

1
2
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

12 years, 12 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

12 years, 12 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

12 years, 12 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

12 years, 12 months

1
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2010