[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, 6 months
[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, 6 months
[JBoss JIRA] Created: (JBCLUSTER-140) Examine need for a distributed service registry outside the AS
by Brian Stansberry (JIRA)
Examine need for a distributed service registry outside the AS
--------------------------------------------------------------
Key: JBCLUSTER-140
URL: http://jira.jboss.com/jira/browse/JBCLUSTER-140
Project: JBoss Clustering
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: Q3Y6
Is something like DRM needed outside the AS? If it is, do we want to use the JBoss Cache based version (creates JBC dependency.)
DRM is used in two ways:
1) To maintain a distributed registry of remote invocation targets.
2) To maintain a distributed registry of services, which is done by having the service register a meaningless token under its key rather than a target. This is used by HASingleton.
Need to examine whether this kind of thing is needed by Messaging, or whether simple listening for view changes is sufficient. Listening for view changes could be sufficient if each group member knew how to create a Remoting InvokerLocator for the other members based on the JGroups Address. But, this presupposes use of consistent ports across the cluster, and that the IP address used by JGroups is the one that Messaging traffic should use.
--
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, 6 months
[JBoss JIRA] Created: (JBRULES-2730) Duplicate rules name errors not being identified across multiple resources in same package
by Michael Pellegrini (JIRA)
Duplicate rules name errors not being identified across multiple resources in same package
------------------------------------------------------------------------------------------
Key: JBRULES-2730
URL: https://jira.jboss.org/browse/JBRULES-2730
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: Windows XP, Java 1.6.0_17
Reporter: Michael Pellegrini
Assignee: Mark Proctor
The validateUniqueRuleNamesmethod in the org.drools.compiler.PackageBuilder class currently only checks for duplicate rule names that are defined within the same resource. However, in the case where there are multiple resources added to the knowledge builder that share the same package name then the validateUniqueRuleNames method is not detecting duplicates across the package.
In cases where rules have the same name and are defined in the same package then I would have expected to get a duplicate rule error but I do not as the rules are physically reside in two separate resources.
It seems logical that in addition to checking if any rules are duplicated within the resource that it also checks to see that rule was already defined in the package registry as well. Otherwise the last rule overwrites the first and creates some rather odd behavior.
--
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, 6 months