September 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-5472) datasource statistics

by Mathieu Lachance (JIRA)

Mathieu Lachance created AS7-5472: ------------------------------------- Summary: datasource statistics Key: AS7-5472 URL: https://issues.jboss.org/browse/AS7-5472 Project: Application Server 7 Issue Type: Bug Components: JCA, JMX Affects Versions: 7.1.2.Final (EAP) Reporter: Mathieu Lachance Assignee: Jesper Pedersen In the java visual vm, in the mbean tab, under the "jboss.as:subsystem=datasources,data-source=MyDataSource" mbean, attribute "statistics" is marked as "Unavailable" When using the spy="true" attribute in the datasource subsystem in conjunction with the "org.jboss.jca" logger set as TRACE level in the logging subsystem, statistics are outputted as follow : Statistics: ActiveCount: 1 AvailableCount: 99 AverageBlockingTime: 0 AverageCreationTime: 248 CreatedCount: 1 DestroyedCount: 0 MaxCreationTime: 248 MaxUsedCount: 1 MaxWaitCount: 0 MaxWaitTime: 0 TimedOut: 0 TotalBlockingTime: 0 TotalCreationTime: 248 I would except to find those statistics available through separates jmx attributes when using the spy="true". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

3
9
0 / 0

[JBoss JIRA] (JGRP-1405) TP: pool of hashmaps for message bundling

by Bela Ban (Created) (JIRA)

TP: pool of hashmaps for message bundling ----------------------------------------- Key: JGRP-1405 URL: https://issues.jboss.org/browse/JGRP-1405 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.2 We currently have 2 message bundlers i TP: the default bundler which adds messages to a hashmap and, when full, has the sending thread serialize all queued messages into one and send it, and the transfer queue bundler, which has the sending thread place a message into a blocking queue and the dequeuer thread collect and send the bundled messages. The disadvantage of the default bundler is that everyone has to wait adding messages to the hashmap, until message bundling has completed. OTOH, the transfer queue bundler blocks all sending threads when the blocking queue is full. Let's create a third bundler, which behaves like the default bundler, but uses a *pool of hashmaps* rather than one. This way, when one hashmap is full, the other sending threads don't have to wait until bundling is complete, but can continue adding their messages to a different hashmap. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
10
0 / 0

[JBoss JIRA] (JBMESSAGING-1931) Message not delivered to Topic afer node rejions cluster

by Doug Grove (JIRA)

Doug Grove created JBMESSAGING-1931: --------------------------------------- Summary: Message not delivered to Topic afer node rejions cluster Key: JBMESSAGING-1931 URL: https://issues.jboss.org/browse/JBMESSAGING-1931 Project: JBoss Messaging Issue Type: Bug Components: JMS Clustering Affects Versions: 1.4.8.SP5 Environment: JBoss EAP 5.1.2 Reporter: Doug Grove After a node leaves the cluster and then rejoins the cluster, the node does not receive messages posted to clustered topics that are delivered to other nodes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
33
0 / 0

[JBoss JIRA] Created: (JGRP-872) TP: cluster name is shipped with each message

by Bela Ban (JIRA)

TP: cluster name is shipped with each message --------------------------------------------- Key: JGRP-872 URL: https://jira.jboss.org/jira/browse/JGRP-872 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 If a cluster name (the name used in Channel.conect()) is long, because we ship it with each message (in the TP header), this blows up the size of the marshalled messages. Maybe we can canonicalize the cluster name shipped with each message, similar to what we want to do with Addresses, e.g. replace the cluster name with a short. -- 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, 8 months

4
15
0 / 0

[JBoss JIRA] Created: (JGRP-931) Logical addresses: canonicalize UUIDs with IDs (shorts)

by Bela Ban (JIRA)

Logical addresses: canonicalize UUIDs with IDs (shorts) ------------------------------------------------------- Key: JGRP-931 URL: https://jira.jboss.org/jira/browse/JGRP-931 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.9 Instead of using UUIDs as addresses, the cluster members should agree on shorts, e.g. 1 for A, 2 for B and so on, and use these instead of UUIDs. This happens after a certain warmup time. E.g. the coord could assign these IDs, so they're unique. IdAddress and UUID have to be able to do equals() or compareTo() with each other ! Advantage: - we send a short (2 bytes) instead of a UUID (16 bytes) - we use an IdAddress (class with a short) instead of a UUID. This is 6 bytes less per instance - IdAddress might be faster with equals() and hashCode() than UUID -- 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, 8 months

2
12
0 / 0

[JBoss JIRA] Created: (JGRP-1370) Use variable-length encoding for primitive data types int, long, short

by Bela Ban (JIRA)

Use variable-length encoding for primitive data types int, long, short ---------------------------------------------------------------------- Key: JGRP-1370 URL: https://issues.jboss.org/browse/JGRP-1370 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.1 Use variable-length encoding [1], to compress data on the wire even more. We currently compress longs and long ranges, but prefix them with a length byte. Using variable-length encoding, we can save that byte for most values. [1] http://lucene.apache.org/java/2_4_0/fileformats.html#VInt -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
3
0 / 0

[JBoss JIRA] (JGRP-1507) MFC2: multicast flow control

by Bela Ban (JIRA)

Bela Ban created JGRP-1507: ------------------------------ Summary: MFC2: multicast flow control Key: JGRP-1507 URL: https://issues.jboss.org/browse/JGRP-1507 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.3 The current flow control protocol (MFC) is slowing things down when we have high traffic in multicast networks (UDP based stack), especially when ethernet flow control (802.3) is disabled. One reason is that the number of credits (similar to the window size in TCP) is static, and doesn't change. E.g. it doesn't increase when there's no loss and doesn't shrink when there is loss. (This will be addressed by a different JIRA later) Another reason is that sender credits are currently only used up when *sending* messages, but not when *receiving* messages. Thus, if we have 50MB of credits, a sender A can send 50MB until A blocks. However, when it receives 20MB of traffic from B while it sends the 50MB, it doesn't take the 20MBs into account. Therefore, a receiver S can be overwhelmed by receiving both A's and B's traffic (the switch might even start discarding messages before they reach S). The change from MFC to MFC2 is that a sender only maintains 1 'credits' counter (number of bytes): whenever it sends a message, it decrements credits. Whenever it receives traffic from someone else, it also decrements credits. When credits is 0, the sender blocks (asking for more credits). When credits drops below a certain threshold, it multicasts 1/N of the max credits (N = number of cluster members). [TBD: perhaps it should mcast a fixed number, independent of the cluster size]. The advantage of this scheme is that a sender blocks sooner, and not when it's too late (congestion). Example: - credits = 100MB - Concurrently: A sends 50MB, B sends 30MB and C sends 60MB - At time T1, A has sent 20MB, and we've already received 10MB from B and 20 from C, credits is now 50MB - At time T2, A sent another 20MB, received 20MB from C. credits is now 10MB, and A multicasts 35MB (rounded) - At T3, A receives another 10MB from C - At T4, A blocks trying to send its remaining 10MBs, as credits = 0 - At T5, A receives its 35MB of credits and sends its remaining 10MB, and also receives 20MB from C, and the remaining 10MB from B. credits is now -5 and A would block sending more credits - At T6, A multicasts 35MBs of credits - At T7, A receives 35MB of credits from B and C, credits= ca 65MB - At T8, A receives its own 35MBs of credits, credits=~100MB -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
5
0 / 0

[JBoss JIRA] (JGRP-1491) Views are created with the wrong view creator

by David Hotham (JIRA)

David Hotham created JGRP-1491: ---------------------------------- Summary: Views are created with the wrong view creator Key: JGRP-1491 URL: https://issues.jboss.org/browse/JGRP-1491 Project: JGroups Issue Type: Bug Affects Versions: 3.1 Reporter: David Hotham Assignee: Bela Ban - At a merge, the merge leader creates a view in which the ViewId.creator is not itself. - This opens the possibility that two different nodes might simultaneously be creating different views - but with the same ViewId - This is bound to lead to confusion, if it happens This is per pull request 54, which contains further discussion and a proposed fix. (I'm raising this ticket just to have everything tracked in one place). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
4
0 / 0

[JBoss JIRA] (AS7-5481) OSGi WebApplicationBundle with a non .wab extension does not work.

by David Bosschaert (JIRA)

David Bosschaert created AS7-5481: ------------------------------------- Summary: OSGi WebApplicationBundle with a non .wab extension does not work. Key: AS7-5481 URL: https://issues.jboss.org/browse/AS7-5481 Project: Application Server 7 Issue Type: Feature Request Components: OSGi, Web Affects Versions: 7.2.0.Alpha1 Reporter: David Bosschaert Assignee: Thomas Diesler Deploying the attached OSGi WAB works: >From the CLI: {{ deploy /Users/david/tmp/bundle-c.wab}} Then open the web address in the browser: {{http://127.0.0.1:8080/osgi-webapp/simple?input=Hello}} However, when changing the extension of the WAB to .jar the WAB doesn't work any more: >From the CLI: {{ deploy /Users/david/tmp/bundle-c.jar}} However you'll get a 404 when trying to access the same WEB address as above. OSGi WAB's are not required to have the .wab extension by spec and it's actually quite common that they simply have a .jar extension. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
4
0 / 0

[JBoss JIRA] (AS7-5482) Improve regularity of CLI syntax to add connection-definition in resource-adapter subsystem

by Akram Ben Aissi (JIRA)

Akram Ben Aissi created AS7-5482: ------------------------------------ Summary: Improve regularity of CLI syntax to add connection-definition in resource-adapter subsystem Key: AS7-5482 URL: https://issues.jboss.org/browse/AS7-5482 Project: Application Server 7 Issue Type: Enhancement Components: CLI Affects Versions: 7.1.2.Final (EAP) Reporter: Akram Ben Aissi Assignee: Alexey Loubyansky The syntax to add a pool in a connection-definition in resource-adapter subsystem is not as regular as expected in comparison with the other CLI commands. e.g: To set the min-pool-size /subsystem=resource-adapters/resource-adapter=wmq.jmsra.rar/connection-definitions=MQConnectionFactory:write-attribute(name=min-pool-size,value=10) Where the XML is: <connection-definitions> <connection-definition class-name="com.ibm.mq.connector.outbound.ManagedQueueConnectionFactoryImpl" jndi-name="java:/jboss/jms/wmqcf" use-java-context="true" pool-name="MQConnectionFactory"> <pool> <min-pool-size>1</min-pool-size> <max-pool-size>10</max-pool-size> </pool> </connection-definition> One would expect the syntax to be more: /subsystem=resource-adapters/resource-adapter=wmq.jmsra.rar/connection-definitions=MQConnectionFactory/pool:write-attribute(name=min-pool-size,value=10) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
3
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 September 2012