July 2011 - 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

14 years, 9 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

14 years, 9 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-290) Not able to created a distributed cache

by Rick Dong (JIRA)

Not able to created a distributed cache --------------------------------------- Key: JBCLUSTER-290 URL: https://jira.jboss.org/browse/JBCLUSTER-290 Project: JBoss Clustering Issue Type: Bug Security Level: Public (Everyone can see) Components: HA-Server-Cache-ISPN Affects Versions: HA-Server-Cache-ISPN 1.0.0.Final Reporter: Rick Dong Assignee: Brian Stansberry if changing the cluster mode to 'distribution', the properties would not be carried over from the default configuration and CHANNEL_LOOKUP would be missing which resulting in the following exception: Caused by: java.lang.Exception: unable to load class for protocol UFC (either as an absolute - UFC - or relative - org.jgroups.protocols.UFC - package name)! at org.jgroups.stack.Configurator$ProtocolConfiguration.createLayer(Configurator.java:1241) at org.jgroups.stack.Configurator$ProtocolConfiguration.access$000(Configurator.java:1132) at org.jgroups.stack.Configurator.createProtocols(Configurator.java:363) at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:89) at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:55) at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:453) at org.jgroups.JChannel.init(JChannel.java:1699) ... 30 more this seems to be caused by the fix to https://jira.jboss.org/browse/ISPN-744 below is the configuration for infinispan: <?xml version="1.0" encoding="UTF-8"?> <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:infinispan:config:4.2 http://www.infinispan.org/schemas/infinispan-config-4.2.xsd" xmlns="urn:infinispan:config:4.2">    <global>  <asyncListenerExecutor factory="org.infinispan.executors.DefaultExecutorFactory"> <properties> <property name="maxThreads" value="5"/> <property name="threadNamePrefix" value="AsyncListenerThread"/> </properties> </asyncListenerExecutor> <asyncTransportExecutor factory="org.infinispan.executors.DefaultExecutorFactory"> <properties> <property name="maxThreads" value="25"/> <property name="threadNamePrefix" value="AsyncSerializationThread"/> </properties> </asyncTransportExecutor> <evictionScheduledExecutor factory="org.infinispan.executors.DefaultScheduledExecutorFactory"> <properties> <property name="threadNamePrefix" value="EvictionThread"/> </properties> </evictionScheduledExecutor> <replicationQueueScheduledExecutor factory="org.infinispan.executors.DefaultScheduledExecutorFactory"> <properties> <property name="threadNamePrefix" value="ReplicationQueueThread"/> </properties> </replicationQueueScheduledExecutor> <globalJmxStatistics enabled="true" jmxDomain="infinispan"/>  <transport clusterName="infinispan-cluster" machineId="m1" rackId="r1" siteId="s1" distributedSyncTimeout="50000" nodeName="Jalapeno"/>    <serialization marshallerClass="org.infinispan.marshall.VersionAwareMarshaller" version="1.0"/>  <shutdown hookBehavior="DEFAULT"/> </global>     <default>  <locking isolationLevel="REPEATABLE_READ" lockAcquisitionTimeout="20000" writeSkewCheck="false" concurrencyLevel="500" useLockStriping="true" />  <transaction transactionManagerLookupClass="org.infinispan.transaction.lookup.GenericTransactionManagerLookup" syncRollbackPhase="false" syncCommitPhase="false" useEagerLocking="true" eagerLockSingleNode="true"/>  <jmxStatistics enabled="false"/> <lazyDeserialization enabled="false"/>  <invocationBatching enabled="true"/>  <clustering mode="d"> </clustering> </default> </infinispan> and the jgroup stack config <?xml version="1.0" encoding="UTF-8"?>  <protocol_stacks> <stack name="udp" description="Default: IP multicast based stack, with flow control and message bundling"> <config> <UDP mcast_addr="${jgroups.udp.mcast_addr:228.10.10.10}" mcast_port="${jgroups.udp.mcast_port:45588}" tos="8" ucast_recv_buf_size="20000000" ucast_send_buf_size="640000" mcast_recv_buf_size="25000000" mcast_send_buf_size="640000" loopback="true" discard_incompatible_packets="true" max_bundle_size="64000" max_bundle_timeout="30" use_incoming_packet_handler="true" ip_ttl="${jgroups.udp.ip_ttl:2}" enable_bundling="${jgroup.udp.enable_bundling:true}" use_concurrent_stack="true" thread_pool.enabled="true" thread_pool.min_threads="1" thread_pool.max_threads="25" thread_pool.keep_alive_time="5000" thread_pool.queue_enabled="false" thread_pool.queue_max_size="100" thread_pool.rejection_policy="Run" oob_thread_pool.enabled="true" oob_thread_pool.min_threads="1" oob_thread_pool.max_threads="8" oob_thread_pool.keep_alive_time="5000" oob_thread_pool.queue_enabled="false" oob_thread_pool.queue_max_size="100" oob_thread_pool.rejection_policy="Run"/> <PING timeout="${jgroups.ping.timeout:2000}" num_initial_members="${jgroups.ping.num_initial_members:3}"/> <MERGE2 max_interval="100000" min_interval="20000"/> <FD_SOCK/> <FD timeout="10000" max_tries="5" shun="true"/> <VERIFY_SUSPECT timeout="1500" /> <pbcast.NAKACK use_mcast_xmit="false" gc_lag="0" retransmit_timeout="300,600,1200,2400,4800" discard_delivered_msgs="false"/> <UNICAST timeout="300,600,1200,2400,3600"/> <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000" max_bytes="400000"/> <pbcast.GMS print_local_addr="true" join_timeout="3000" shun="false" view_bundling="true" view_ack_collection_timeout="5000"/> <FC max_credits="2000000" min_threshold="0.10"/> <FRAG2 frag_size="60000" /> <pbcast.STREAMING_STATE_TRANSFER/>  <pbcast.FLUSH timeout="0"/> </config> </stack> </protocol_stacks> -- 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, 9 months

2
5
0 / 0

[JBoss JIRA] Assigned: (JBCLUSTER-119) Effect of different JGroups transports

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/JBCLUSTER-119?page=com.atlassian.jira.plu... ] Brian Stansberry reassigned JBCLUSTER-119: ------------------------------------------ Assignee: (was: Brian Stansberry) > Effect of different JGroups transports > -------------------------------------- > > Key: JBCLUSTER-119 > URL: https://issues.jboss.org/browse/JBCLUSTER-119 > Project: JBoss Clustering > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Web Tier > Reporter: Brian Stansberry > Fix For: Legacy > > Attachments: ResultsExtract.pdf, tc5-cluster-service.xml.nio, tc5-cluster-service.xml.tcp, tc5-cluster-service.xml.udp > > > Need to see in which cluster topologies UDP, TCP and TCP_NIO perform best. Particularly, how big of a cluster before UDP pays off. Need to factor buddy replication into this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 9 months

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

14 years, 9 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

14 years, 9 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

14 years, 9 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

14 years, 9 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

14 years, 9 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

14 years, 9 months

1
1
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 July 2011