July 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-9362) Long running thread leaks SimpleRole objects

by Tim Terlegard (JIRA)

Long running thread leaks SimpleRole objects -------------------------------------------- Key: JBAS-9362 URL: https://issues.jboss.org/browse/JBAS-9362 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Security Affects Versions: 6.0.0.Final Environment: Tested on Mac OS X 10.6.7 with Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-334, mixed mode) 1.6.0_24 Reporter: Tim Terlegard Assignee: Anil Saldhana Attachments: simpleroletest.tar.gz When invoking a long-running EJB method which makes a bunch of calls to some method in another EJB, then JBoss leaks SimpleRole objects. The SimpleRole objects are not removed by a manually triggered garbage collection. The SimpleRole object leakage seems to go away if I remove the security domain in jboss.xml. When running my jboss application during the night JBoss had 4GB of SimpleRole objects. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

6
9
0 / 0

[JBoss JIRA] (AS7-3288) Logger add operation still shows "category" attribute in :read-operation-description

by Stan Silvert (JIRA)

Stan Silvert created AS7-3288: --------------------------------- Summary: Logger add operation still shows "category" attribute in :read-operation-description Key: AS7-3288 URL: https://issues.jboss.org/browse/AS7-3288 Project: Application Server 7 Issue Type: Bug Components: Logging Affects Versions: 7.1.0.CR1b Reporter: Stan Silvert Assignee: James Perkins I think we eliminated the "category" parameter as redundant? It still shows up when you do a :read-operation-description /subsystem=logging/logger=bogus/:read-operation-description(name=add) Specifying the category on an add operation seems to have no effect. -- 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, 10 months

3
3
0 / 0

[JBoss JIRA] (JBJCA-856) Support deployment from remote location

by Jesper Pedersen (JIRA)

Jesper Pedersen created JBJCA-856: ------------------------------------- Summary: Support deployment from remote location Key: JBJCA-856 URL: https://issues.jboss.org/browse/JBJCA-856 Project: IronJacamar Issue Type: Task Components: Deployer Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.1.0.Beta2 Add support for deploying archives from a remote location. Introduce the "remote-deploy", "remote-undeploy" and "remote-list" commands, and put the deployments into deploy/remote -- 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, 10 months

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

13 years, 10 months

1
7
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, 10 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, 10 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, 10 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, 10 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, 10 months

2
3
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, 10 months

2
4
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 July 2012