September 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-5490) No bundle notifications on shutdown

by Thomas Diesler (JIRA)

Thomas Diesler created AS7-5490: ----------------------------------- Summary: No bundle notifications on shutdown Key: AS7-5490 URL: https://issues.jboss.org/browse/AS7-5490 Project: Application Server 7 Issue Type: Bug Components: OSGi Reporter: Thomas Diesler Assignee: Thomas Diesler Fix For: 7.2.0.CR1 -- 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

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (AS7-4857) instead of injecting javassist into deployment, Hibernate ORM should export it (same goes for envers).

by Scott Marlow (JIRA)

Scott Marlow created AS7-4857: --------------------------------- Summary: instead of injecting javassist into deployment, Hibernate ORM should export it (same goes for envers). Key: AS7-4857 URL: https://issues.jboss.org/browse/AS7-4857 Project: Application Server 7 Issue Type: Task Components: JPA / Hibernate Affects Versions: 7.1.2.Final (EAP) Reporter: Scott Marlow Assignee: Scott Marlow Fix For: 7.2.0.Alpha1 -- 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

11 years, 7 months

1
7
0 / 0

[JBoss JIRA] (AS7-5289) Tests failing Intermittently on slow machines - XTS WSAT, WSBA

by Ondrej Zizka (JIRA)

Ondrej Zizka created AS7-5289: --------------------------------- Summary: Tests failing Intermittently on slow machines - XTS WSAT, WSBA Key: AS7-5289 URL: https://issues.jboss.org/browse/AS7-5289 Project: Application Server 7 Issue Type: Bug Components: Test Suite Affects Versions: 7.1.2.Final (EAP) Reporter: Ondrej Zizka Assignee: Ivo Studensky These tests fail intermintently on really slow machines. To reproduce, try to run in EC2 on 32-bit "small" instance type. >>> org.jboss.as.test.xts.simple.wsat.client.WSATTestCase.testCommit >>> org.jboss.as.test.xts.simple.wsat.client.WSATTestCase.testRollback >>> org.jboss.as.test.xts.simple.wsba.coordinatorcompletion.client.WSBACoordinatorCompletionTestCase.testSuccess >>> org.jboss.as.test.xts.simple.wsba.coordinatorcompletion.client.WSBACoordinatorCompletionTestCase.testCancel >>> org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase.testSuccess >>> org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase.testCancel -- 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

11 years, 7 months

2
4
0 / 0

[JBoss JIRA] (AS7-4140) Change distribution of -Dmcast through testsuite

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/AS7-4140?page=com.atlassian.jira.plugin.s... ] Ondrej Zizka reopened AS7-4140: ------------------------------- JBPAPP-8400 is fixed now. To keep the code in sync, we should apply the fix to AS as well. > Change distribution of -Dmcast through testsuite > ------------------------------------------------ > > Key: AS7-4140 > URL: https://issues.jboss.org/browse/AS7-4140 > Project: Application Server 7 > Issue Type: Feature Request > Components: Test Suite > Affects Versions: 7.1.1.Final > Reporter: Pavel Janousek > Assignee: Ondrej Zizka > Priority: Minor > Fix For: 7.1.2.Final (EAP) > > > Please change present behavior. > We need to define only one property -Dmcast (for ex., the name doesn't matter now) as command line parameter - this multicast address is needed to be distributed to every subsystem which manages any multicast communication. It is needed to be unique in every subsystem - JGroups, HornetQ etc. because we must avoid to interfere each other => port assignation must be unique for every a such component. > This change is needed in both - IPV4 and IPv6... -- 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

11 years, 7 months

1
0
0 / 0

[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

11 years, 7 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

11 years, 7 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

11 years, 7 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

11 years, 7 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

11 years, 7 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

11 years, 7 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2012