January 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-3416) Register javax.naming.spi.ObjectFactory from OSGi Service Layer with AS7 Naming

by David Bosschaert (JIRA)

David Bosschaert created AS7-3416: ------------------------------------- Summary: Register javax.naming.spi.ObjectFactory from OSGi Service Layer with AS7 Naming Key: AS7-3416 URL: https://issues.jboss.org/browse/AS7-3416 Project: Application Server 7 Issue Type: Task Components: OSGi Affects Versions: 7.1.0.CR1b Reporter: David Bosschaert Assignee: Thomas Diesler Fix For: 7.1.0.Final OSGi/JNDI spec compliant implementations will provide ObjectFactory objects in the ServiceRegistry. For the JavaEE JNDI layer to be able to use the osgi: JNDI scheme (and this integrate with the OSGi layer through JNDI) these objects need to be registered with the org.jboss.as.naming.InitialContext.addUrlContextFactory() API -- 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

14 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-2293) Classpath resources being scanned by ResourceChangeScanner could cause improper resource removal

by Steve Ronderos (JIRA)

Classpath resources being scanned by ResourceChangeScanner could cause improper resource removal ------------------------------------------------------------------------------------------------ Key: JBRULES-2293 URL: https://jira.jboss.org/jira/browse/JBRULES-2293 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.0.1.FINAL Environment: Windows XP Java 5 Running in Oracle OC4J 10.1.3.2 Reporter: Steve Ronderos Assignee: Mark Proctor I encountered an issue today with my KnowledgeAgent removing resources from its RuleBase shortly after creating it. I have the ResourceChangeScanner running in my application. I tracked the issue back to the scan() method in ResourceChangeScannerImpl. It appears that the method is trying to identify resources that are no longer available and remove them from both the RuleBase and future scans. To do this it is checking lastModified on the resource and on a result of 0 removing the resource. The resources that I configured in my change-set definitely still exist, but due to URL handler implementation provided by my classloader, getLastModified always returns 0. (The resource I'm retrieving is coming from a jar that is in my application's classpath and the URL handler implementation is oracle.classloader.SharedCodeSourceURL) Full Email Group trail: http://www.nabble.com/Issue-with-ResourceChangeScanner-td25792358.html Michael recommends to never scan classpath resources. -- 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

14 years, 3 months

6
13
0 / 0

[JBoss JIRA] (AS7-2465) Hang in org.jboss.as.test.integration.domain.DeploymentManagementTestCase

by Carlo de Wolf (Created) (JIRA)

Hang in org.jboss.as.test.integration.domain.DeploymentManagementTestCase ------------------------------------------------------------------------- Key: AS7-2465 URL: https://issues.jboss.org/browse/AS7-2465 Project: Application Server 7 Issue Type: Bug Reporter: Carlo de Wolf Attachments: 10964-jstack.txt -- 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

14 years, 3 months

6
5
0 / 0

[JBoss JIRA] (AS7-2083) Exception when specifying discovery-group-ref under connection-factory / pooled-connection-factory in messaging subsystem

by Evangelos Parchas (Created) (JIRA)

Exception when specifying discovery-group-ref under connection-factory / pooled-connection-factory in messaging subsystem ------------------------------------------------------------------------------------------------------------------------- Key: AS7-2083 URL: https://issues.jboss.org/browse/AS7-2083 Project: Application Server 7 Issue Type: Bug Components: JMS Affects Versions: 7.0.1.Final Environment: Ubuntu 11.04 64bit, Java 1.6 Reporter: Evangelos Parchas Assignee: Clebert Suconic An error is produced when specifying a "discovery-group-ref" under either a "connection-factory" or "pooled-connection-factory" in the messaging subsystem configuration: {code} <connection-factory name="RemoteConnectionFactory"> <discovery-group-ref discovery-group-name="dg-group1"/> <entries> <entry name="java:/RemoteConnectionFactory"/> </entries> </connection-factory> {code} {code} <pooled-connection-factory name="RemoteXAConnectionFactory"> <discovery-group-ref discovery-group-name="dg-group1"/> <entries> <entry name="java:/RemoteXAConnectionFactory"/> </entries> <transaction mode="xa"/> </pooled-connection-factory> {code} The exception present in the server.log is: {code} 14:40:45,466 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-16) MSC00001: Failed to start service jboss.raactivator: org.jboss.msc.service.St artException in service jboss.raactivator: Failed to activate resource adapter RemoteXAConnectionFactory at org.jboss.as.connector.services.ResourceAdapterActivatorService.start(ResourceAdapterActivatorService.java:98) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765) at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26] at java.lang.Thread.run(Thread.java:662) [:1.6.0_26] Caused by: org.jboss.jca.deployers.common.DeployException: Deployment org.hornetq.ra.HornetQResourceAdapter failed at org.jboss.as.connector.metadata.deployment.AbstractResourceAdapterDeploymentService$AbstractAS7RaDeployer.initAndInject(AbstractResourceAdap terDeploymentService.java:382) at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:900) at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:825) at org.jboss.as.connector.services.ResourceAdapterActivatorService$ResourceAdapterActivator.doDeploy(ResourceAdapterActivatorService.java:140) at org.jboss.as.connector.services.ResourceAdapterActivatorService.start(ResourceAdapterActivatorService.java:93) ... 5 more Caused by: java.lang.NoSuchMethodException: org.hornetq.ra.HornetQResourceAdapter.setDiscoveryGroupName(java.lang.String) at java.lang.Class.getMethod(Class.java:1605) [:1.6.0_26] at org.jboss.as.connector.util.Injection.inject(Injection.java:149) at org.jboss.as.connector.metadata.deployment.AbstractResourceAdapterDeploymentService$AbstractAS7RaDeployer.initAndInject(AbstractResourceAdap terDeploymentService.java:374) ... 9 more {code} Looking at HornetQResourceAdapter, it does not provide a method called "setDiscoveryGroupName" but a "setDiscoveryAddress" which bears the javadoc that it corresponds to the discovery group name. This prevents successful configuration of the messaging subsystem for clustered environments -- 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

14 years, 3 months

6
6
0 / 0

[JBoss JIRA] (JBMETA-351) Missing parser support for replication-config and passivation-config

by Paul Ferraro (JIRA)

Paul Ferraro created JBMETA-351: ----------------------------------- Summary: Missing parser support for replication-config and passivation-config Key: JBMETA-351 URL: https://issues.jboss.org/browse/JBMETA-351 Project: JBoss Metadata Issue Type: Bug Security Level: Public (Everyone can see) Components: web Affects Versions: 7.0.0.Beta31 Reporter: Paul Ferraro Assignee: Paul Ferraro Priority: Blocker Fix For: 7.0.0.Beta32 -- 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

14 years, 3 months

1
3
0 / 0

[JBoss JIRA] Created: (JGRP-1361) NAKACK: use bigger timeouts for big retransmission tasks

by Bela Ban (JIRA)

NAKACK: use bigger timeouts for big retransmission tasks -------------------------------------------------------- Key: JGRP-1361 URL: https://issues.jboss.org/browse/JGRP-1361 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.1 Oftentimes we receive messages out of order, e.g. because an OOB message follows a range of regular messages, but since the regular messages are bundled, they ay arrive later than the OOB message. Say the regular messages are [10-30] and the OOB message is 31. Receiving #31 before #10-30 triggers the addition of a retransmission task for [10..30] to the retransmitter. The task usually goes off after some initial delay, say 500ms. If we receive [10..30] before the task goes off, it will be cancelled. If we receive most of the messages in [10..30], only the missing messages will get retransmitted when the task fires. So in most cases, a lot of retransmission tasks will never fire and are cancelled before. However, sometimes we can receive a seqno which is way larger than the currently highest_received seqno, e.g. highest_received=15000, seqno=20000. This means we now add a retransmission request for [15000-20000]. It is likely that the seqno was just received out of order, but it may trigger the (unneeded) retransmission of 5000 messages ! The suggested solution is therefore to increase the initial delay for large retransmission tasks, such that they execute a bit later. Of course, the underlying assumption is that most of the missing messages will arrive before the timeout goes off. If the 5000 message are really lost, e.g. dropped by the IP stack or a switch, then they will need to get retransmitted. If we have an exponential_backoff of 500, the initial delay is 500ms. We could say that a 'large' retransmission task is any task which asks for retransmission of more than 10% of the current retransmission table's size. We could compute an offset to the initial delay, which is added to the delay (only the first time), by using the delta and the current delay. We could add this delta to delay only the first time a retransmission task is scheduled, or we could add this to any retransmission scheduling as long as the task is large. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-1362) NAKACK: second line of defense for requested retransmissions that are not found

by Bela Ban (JIRA)

NAKACK: second line of defense for requested retransmissions that are not found ------------------------------------------------------------------------------- Key: JGRP-1362 URL: https://issues.jboss.org/browse/JGRP-1362 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.12.2, 3.1 When the original sender B is asked by A to retransmit message M, but doesn't have M in its retransmission table anymore, it should tell A, or else A will send retransmission requests to B until A or B leave. This problem should have been fixed by JGRP-1251, but if it turns out it wasn't, then this JIRA is (1) a second line of defense to stop the endless retransmission requests and (2) will give us valuable diagnostic information to fix the underlying problem (should there still be one). Problem: - A has a NakReceiverWindow (NRW) of 50 (highest_delivered seqno) for B - B's NRW, however, is 200. B garbage collected messages up to 150. - When B sends message 201, A will ask B for retransmission of [51-200] - B will retransmit messages [150-200], but it cannot send messages 51-149, as it doesn't have them anymore ! - A will add messages [150-200], but its NRW is still 50 (highest_delivered) - A will continue asking B for messages [51-149] (it does have [150-201]) - This will go on forever, or until B or A leaves SOLUTION: - When the *original sender* B of message M receives a retransmission request for M (from A), and it doesn't have M in its retransmission table, it should send back a MSG_NOT_FOUND message to A including B's digest - When A receives the MSG_NOT_FOUND message, it does the following: - It logs it own NRW for B - It logs B's digest - It logs its digest history (This information is valuable for investigating the underlying issue) - Then A's NRW for B is adjusted: - The highest_delivered seqno is set to B.digest.highest_delivered - All messages in xmit_table below B.digest.highest_delivered are removed - All retransmission tasks in the retransmitter <= B.digest.highest_delivered are cancelled and removed (This will stop the retransmission) Again, this is a second line of defense, which should never be used. If the underlying problem does occur, however, we'll have valuable information in the logs to diagnose what went wrong. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

2
3
0 / 0

[JBoss JIRA] (JGRP-1396) Merge NakreceiverWindow and Retransmitter

by Bela Ban (Created) (JIRA)

Merge NakreceiverWindow and Retransmitter ----------------------------------------- Key: JGRP-1396 URL: https://issues.jboss.org/browse/JGRP-1396 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.2 Both NakReceiverWindow and Retransmitter use their own data structures to keep a list of messages received (NRW) and seqnos to be retransmitted (Retrasmitter). This is redundant and costly memory-wise. I suggest let's merge the 2 classes, or at least let them share the data structure which keeps track of received messages. Suggestion II: create a ring buffer with a (changeable) capacity that keeps track of received messages and messages to be retransmitted. -- 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

14 years, 3 months

5
17
0 / 0

[JBoss JIRA] (JGRP-1402) NAKACK: too much lock contention between sending and receiving messages

by Bela Ban (Created) (JIRA)

NAKACK: too much lock contention between sending and receiving messages ----------------------------------------------------------------------- Key: JGRP-1402 URL: https://issues.jboss.org/browse/JGRP-1402 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.2 When we have only 1 node in a cluster, sending and receiving messages creates a lot of contention in NakReceiverWindow (NRW). To reproduce: - Start MPerf - Press '1' to send 1 million messages - The throughput is ca 20-30 MB/sec, compared to 140 MB when running multiple instances of MPerf on the same box ! In the profiler, we can see that the write lock in NRW makes up for ca 99% of all the blocking ! Ca. half is caused by NRW.add(), the other half by NRW.removeMany(). The reason is that, when we send a message, it is added to the NRW (add()). The incoming thread then tries to remove as many messages as possible (removeMany()), and blocks messages being added to NRW by the sender, and vice versa; the removeMany() method is blocked accessing the NRW by many add()s. SOLUTION 1: - If we only have 1 member in the cluster, call removeMany() immediately after NRW.add() on the sender. No need for a message to be processed by the incoming thread pool, if we're the only member in the cluster - The downside here is that we don't reduce the contention on NRW if we have more than 1 member: this lock contention may even slow down the case of more than 1 member clusters ! SOLUTION 2: - Make NRW.add() and remove() more efficient, and contend less on the same lock. - [1] should help. [1] https://issues.jboss.org/browse/JGRP-1396 -- 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

14 years, 3 months

4
3
0 / 0

[JBoss JIRA] (AS7-2557) Management Console support for JPA

by Scott Marlow (Created) (JIRA)

Management Console support for JPA ---------------------------------- Key: AS7-2557 URL: https://issues.jboss.org/browse/AS7-2557 Project: Application Server 7 Issue Type: Feature Request Components: Console Reporter: Scott Marlow Assignee: Heiko Braun -- 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

14 years, 3 months

5
6
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 January 2012