[JBoss JIRA] (AS7-6124) Support JGroups Channel in messaging pooled-connection-factory
by Jeff Mesnil (JIRA)
Jeff Mesnil created AS7-6124:
--------------------------------
Summary: Support JGroups Channel in messaging pooled-connection-factory
Key: AS7-6124
URL: https://issues.jboss.org/browse/AS7-6124
Project: Application Server 7
Issue Type: Enhancement
Components: JMS
Affects Versions: 7.2.0.Alpha1
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
HornetQ 2.3.0.BETA2 allows its RA to use JGroups for discovery but the AS7 messaging subsystem does not provide the attributes to configure its pooled-connection-factory with JGroups
--
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, 7 months
[JBoss JIRA] (JASSIST-163) RuntimeSupport.find2Methods a perf hotspot when proxy's methods are called at higher concurrency
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/JASSIST-163?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on JASSIST-163:
--------------------------------------
I'm not sure why, but only when we are using 3.17.1, we experience a new Hibernate test regression https://hibernate.onjira.com/browse/HHH-7850.
The generated test class disassembled is here http://pastie.org/5494599 and failure exception is here http://pastie.org/5494609
It seems obvious to me that we need to fix this in the Hibernate [BulkAccessorFactory|https://github.com/hibernate/hibernate-orm/blob/4.1/h...] class by generating the StackMapTable (as mentioned in the comments of the above jira).
Why do we need to change BulkAccessorFactory with Javassist 3.17.1 but not 3.15.0?
> RuntimeSupport.find2Methods a perf hotspot when proxy's methods are called at higher concurrency
> ------------------------------------------------------------------------------------------------
>
> Key: JASSIST-163
> URL: https://issues.jboss.org/browse/JASSIST-163
> Project: Javassist
> Issue Type: Enhancement
> Affects Versions: 3.15.0-GA, 3.16.1-GA
> Environment: hibernate-core 3.6.10.Final
> Reporter: Nikita Tovstoles
> Assignee: Shigeru Chiba
> Fix For: 3.17.0-GA
>
> Attachments: Bean_$$_bulkaccess_0.txt, Bean_$$_bulkaccess_0_Two.txt, blocked-threads.png, BulkAccessorFactory.java.diff, BulkAccessorFactory.java.diff2, BulkAccessorFactory.patch, find2methods-hotspot.png, jassist-163-fix.patch, monitor-backtraces.png, monitor-backtraces.png, Product.java, Product_$$_javassist_0-post-patch.java, Product_$$_javassist_0.java, Tomcat-2012-03-28(2).zip
>
>
> We've been profiling our Hibernate 3.6.10-based app and noticed a perf bottleneck in javassist.util.proxy.RuntimeSupport.find2methods. Unfortunately, this method, which has a synch. block, is being called on
> every invocation of every proxied entity method (see javassist.util.proxy.ProxyFactory.makeForwarder(), called indirectly by
> ProxyFactory.createClass()).
> In our testing, the result is that our service call's latency increases from 33 to 55, 260, 400ms as concurrency increases
> 1-10-20-30 users on a 4-core CPU. At 20 and 30 users 51% of CPU time is spent contending for a monitor in RuntimeSupport.find2methods:
> {code}
> synchronized (methods) {
> if (methods[index] == null) {
> methods[index + 1] = thisMethod == null ? null
> : findMethod(self, thisMethod, desc);
> methods[index] = findSuperMethod(self, superMethod, desc);
> }
> }
> {code}
> Since find2methods merely interrogates class metadata, seems like its return values should be cached (in a ConcurrentMap?) instead of repeatedly executing the above synchronized statement. Instead, currently, it's being called every time (?) a proxied method is executed - see *Invocation Count* in this screen shot:
> https://issues.jboss.org/secure/attachment/12353025/monitor-backtraces.png
> Full [YourKit profile|http://yourkit.com] is [attached as a ZIP archive|^Tomcat-2012-03-28(2).zip]; key screen shots from the snapshot also attached separately
--
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, 7 months
[JBoss JIRA] (JBJCA-941) NPE in ResourceAdapter1516Impl for invalid RAR
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/JBJCA-941?page=com.atlassian.jira.plugin.... ]
Jesper Pedersen resolved JBJCA-941.
-----------------------------------
Resolution: Done
Thanks Philippe
> NPE in ResourceAdapter1516Impl for invalid RAR
> ----------------------------------------------
>
> Key: JBJCA-941
> URL: https://issues.jboss.org/browse/JBJCA-941
> Project: IronJacamar
> Issue Type: Bug
> Components: Common
> Affects Versions: 1.0.13.Final, 1.1.0.Beta3
> Reporter: Philippe Marschall
> Assignee: Jesper Pedersen
> Labels: patch
> Fix For: 1.0.14.Final, 1.1.0.Beta4
>
> Attachments: JBJCA-941.patch
>
>
> In case of an invalid RAR (JCA 1.6 but not adapter class) you get the following deployment error in JBoss AS.
> {code}
> 15:38:22,236 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.deployment.subunit."sample-application-1.0.0-SNAPSHOT.ear"."sample-adapter-1.0.0-SNAPSHOT.rar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."sample-application-1.0.0-SNAPSHOT.ear"."sample-adapter-1.0.0-SNAPSHOT.rar".INSTALL: JBAS018733: Failed to process phase INSTALL of subdeployment "sample-adapter-1.0.0-SNAPSHOT.rar" of deployment "sample-application-1.0.0-SNAPSHOT.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:127) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.8.0-ea]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.8.0-ea]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.8.0-ea]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException
> at org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor.deploy(ParsedRaDeploymentProcessor.java:185)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:120) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> ... 5 more
> Caused by: java.lang.NullPointerException
> at org.jboss.jca.common.metadata.ra.common.ResourceAdapter1516Impl.validate(ResourceAdapter1516Impl.java:351)
> at org.jboss.jca.common.metadata.ra.common.ConnectorAbstractmpl.validate(ConnectorAbstractmpl.java:332)
> at org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor.deploy(ParsedRaDeploymentProcessor.java:142)
> ... 6 more
> {code}
> It should be a {code}org.jboss.jca.common.api.validator.ValidateException{code} but ends up being a {code}java.lang.NullPointerException{code}. The problem is that {code}ResourceAdapter1516Impl#validate(){code} uses
> {code}
> this.resourceadapterClass == null
> {code}
> instead of
> {code}
> XsdString.isNull(this.resourceadapterClass)
> {code}
> like {code}#getResourceadapterClass(){code} or the constructor.
> {code}
> this.resourceadapterClass.getValue()
> {code}
> then returns {code}null{code} so
> {code}
> this.resourceadapterClass.getValue().trim()
> {code}
> throws a {code}NullPointerException{code}
--
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, 7 months
[JBoss JIRA] (AS7-430) DomainController discovery system
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/AS7-430?page=com.atlassian.jira.plugin.sy... ]
David Lloyd commented on AS7-430:
---------------------------------
A couple comments.
First I'd like to express that it's great that this has been moving forward, and I think it's definitely an important feature. But I have some reservations about hard-wiring all the different possible discovery options into the main schema. Since many of the possible discovery methods are closely tied to infrastructure, especially when it comes to cloud providers, I think they should come in as pluggable extensions. This does however imply that we need some sort of infrastructure to support host-level pluggable extensions.
> DomainController discovery system
> ---------------------------------
>
> Key: AS7-430
> URL: https://issues.jboss.org/browse/AS7-430
> Project: Application Server 7
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Farah Juma
> Fix For: 7.2.0.CR1
>
>
> Mechanism(s) by which a Host Controller finds a Domain Controller so it can begin the process of integrating into the domain.
> Task includes the host.xml schema elements to configure this, the domain object model classes behind those elements, and the actual implementation of discovery from both the ServerManager and DomainController sides.
--
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, 7 months
[JBoss JIRA] (JGRP-1551) AgePutCache: use 1 timer tasks for all elements rather than 1 task per element
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1551?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1551.
----------------------------
Resolution: Done
> AgePutCache: use 1 timer tasks for all elements rather than 1 task per element
> ------------------------------------------------------------------------------
>
> Key: JGRP-1551
> URL: https://issues.jboss.org/browse/JGRP-1551
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> Currently, AgeOutCache uses 1 task for every element. Change this to 1 task for all elements, so we reduce the number of tasks in the timer.
> AgeOutCache is used e.g. in TP, to see if we've recently requested fetching of a physical address from the discovery protocol, to suppress too many discovery requests.
> The task would be started whenever add() is called and a task is not yet already running. After all elements have expired, the task would terminated until the next add() is called.
--
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, 7 months
[JBoss JIRA] (JGRP-1551) AgePutCache: use 1 timer tasks for all elements rather than 1 task per element
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1551?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1551:
--------------------------------
Actually, I didn't modify AgeOutCache, but created a new ExpiryCache which does *not* use any timer tasks. TP uses it as the new who-has cache, replacing AgeOutCache.
> AgePutCache: use 1 timer tasks for all elements rather than 1 task per element
> ------------------------------------------------------------------------------
>
> Key: JGRP-1551
> URL: https://issues.jboss.org/browse/JGRP-1551
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> Currently, AgeOutCache uses 1 task for every element. Change this to 1 task for all elements, so we reduce the number of tasks in the timer.
> AgeOutCache is used e.g. in TP, to see if we've recently requested fetching of a physical address from the discovery protocol, to suppress too many discovery requests.
> The task would be started whenever add() is called and a task is not yet already running. After all elements have expired, the task would terminated until the next add() is called.
--
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, 7 months
