[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, 6 months
[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">
<!-- *************************** -->
<!-- System-wide global settings -->
<!-- *************************** -->
<global>
<!-- Note that if these are left blank, defaults are used. See the user guide for what these defaults are -->
<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"/>
<!--
If the transport is omitted, there is no way to create distributed or clustered caches.
There is no added cost to defining a transport but not creating a cache that uses one, since the transport
is created and initialized lazily.
-->
<transport clusterName="infinispan-cluster" machineId="m1" rackId="r1" siteId="s1" distributedSyncTimeout="50000" nodeName="Jalapeno"/>
<!-- Note that the JGroups transport uses sensible defaults if no configuration property is defined. -->
<!-- See the JGroupsTransport javadocs for more flags -->
<!-- Again, sensible defaults are used here if this is omitted. -->
<serialization marshallerClass="org.infinispan.marshall.VersionAwareMarshaller" version="1.0"/>
<!--
Used to register JVM shutdown hooks.
hookBehavior: DEFAULT, REGISTER, DONT_REGISTER
-->
<shutdown hookBehavior="DEFAULT"/>
</global>
<!-- *************************** -->
<!-- Default "template" settings -->
<!-- *************************** -->
<!-- this is used as a "template" configuration for all caches in the system. -->
<default>
<!--
isolation levels supported: READ_COMMITTED and REPEATABLE_READ
-->
<locking
isolationLevel="REPEATABLE_READ"
lockAcquisitionTimeout="20000"
writeSkewCheck="false"
concurrencyLevel="500"
useLockStriping="true"
/>
<!-- //http://community.jboss.org/wiki/LockingandConcurrency#Locking_a_single_remote_node
Used to register a transaction manager and participate in ongoing transactions.
-->
<transaction
transactionManagerLookupClass="org.infinispan.transaction.lookup.GenericTransactionManagerLookup"
syncRollbackPhase="false"
syncCommitPhase="false"
useEagerLocking="true" eagerLockSingleNode="true"/>
<!--
Used to register JMX statistics in any available MBean server
-->
<jmxStatistics enabled="false"/>
<lazyDeserialization enabled="false"/>
<!--
Used to enable invocation batching and allow the use of Cache.startBatch()/endBatch() methods.
-->
<invocationBatching enabled="true"/>
<!--
This element specifies that the cache is clustered.
modes supported: distribution (d), replication (r) or invalidation (i).
-->
<clustering mode="d">
</clustering>
</default>
</infinispan>
and the jgroup stack config
<?xml version="1.0" encoding="UTF-8"?>
<!--
Sample file that defines a number of stacks, used by the multiplexer
Author: Bela Ban
Version: $Id: jgroups-stacks.xml 14257 2007-12-23 14:46:37Z bstansberry(a)jboss.com $
-->
<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.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
13 years, 6 months
[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, 6 months