[JBoss JIRA] Created: (JBMESSAGING-1885) Duplicated message delivery in closing a connection while a transaction is committing
by Yong Hao Gao (JIRA)
Duplicated message delivery in closing a connection while a transaction is committing
-------------------------------------------------------------------------------------
Key: JBMESSAGING-1885
URL: https://issues.jboss.org/browse/JBMESSAGING-1885
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.4.8.SP1, 1.4.0.SP3.CP13
Reporter: Yong Hao Gao
Assignee: Yong Hao …
[View More]Gao
Fix For: 1.4.0.SP3.CP14, 1.4.8.SP2
A message may be delivered twice when the following events happens in order:
1. A client receives a message in a transaction and is committing it. In the meantime the connection is closed (by, for example, user shut down the client application) in another thread.
2. At the server side, the connection closing will cause the message (not prepared) to be cancelled back to queue. In the meantime the committing will remove the message. Both actions are performed concurrently.
3. If the committing happens before the connection closing, transaction commit successfully and message won't get cancelled. But if the committing happens after connection closing, there is a chance the message is cancelled back to queue and yet the transaction is committed successfully. So the message will be delivered twice.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
13 years, 9 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 …
[View More]'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
[View Less]
13 years, 9 months