July 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (AS7-1257) Command given in CLI help text is wrong

by Misty Stanley-Jones (JIRA)

Command given in CLI help text is wrong --------------------------------------- Key: AS7-1257 URL: https://issues.jboss.org/browse/AS7-1257 Project: Application Server 7 Issue Type: Bug Components: Server Affects Versions: 7.0.0.CR1 Reporter: Misty Stanley-Jones Assignee: Jason Greene When you are logged into the Management CLI and you type "help", one of the example commands it gives is: e.g. /subsystem=web/connector=http:read-resource(recursive=1) The syntax of the command is really this: /subsystem=web/connector=http:read-resource(recursive=true) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[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 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

13 years, 5 months

1
3
0 / 0

[JBoss JIRA] Created: (AS7-1236) copied lib directory in the deployments directory results in deployment

by Jim Tyrrell (JIRA)

copied lib directory in the deployments directory results in deployment ------------------------------------------------------------------------ Key: AS7-1236 URL: https://issues.jboss.org/browse/AS7-1236 Project: Application Server 7 Issue Type: Feature Request Environment: JBoss AS 7 CR 1 Reporter: Jim Tyrrell Having an existing zipped up war file, and then unzipping it in the deployment directory, creates a lib directory that has a bunch of jar files in it. It appears that these jar files in this lib directory are marked as .failed as they are tried to be deployed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

3
17
0 / 0

[JBoss JIRA] Created: (JBAS-7944) Move GlobalDiscoveryDisableTestCase to defaultcfg package

by Brian Stansberry (JIRA)

Move GlobalDiscoveryDisableTestCase to defaultcfg package --------------------------------------------------------- Key: JBAS-7944 URL: https://jira.jboss.org/jira/browse/JBAS-7944 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, Test Suite Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor Fix For: JBossAS-6.0.0.M4 AFAICT this test doesn't need to be run with different JGroups stacks. -- 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, 5 months

3
4
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

13 years, 5 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

13 years, 5 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

13 years, 5 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

13 years, 5 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

13 years, 5 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

13 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2011