[JBoss JIRA] (AS7-6583) Performance regression comparing to previous release
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/AS7-6583?page=com.atlassian.jira.plugin.s... ]
Tomas Remes commented on AS7-6583:
----------------------------------
Well yes, It's quite weird. The example isn't using any logging. The tests as well as results are available at http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/Weld/view/Weld-Perfo.... IMHO this is bringing the regression https://github.com/jbossas/jboss-as/commit/526c2ae7a4194dc6b787c32c5218ce... (but it could be anything else). Results are following (2000 parallel sessions load):
{noformat}
7.1.3.Final: throughput 1,901.4 samples/s, mean response: 48 ms
7.2.0.Final(prerelease): throughput 1,537.0 samples/s, mean response: 293 ms
7.2.0.Final(prerelease) with logging cb2a3c15cb4a50c41032d27ea560a4f92d6e2b7d: throughput 1,937.9 samples/s, mean response: 27 ms
7.2.0.Final(prerelease) with logging 526c2ae7a4194dc6b787c32c5218cea003276900: throughput 1,537.5 samples/s, mean response: 308 ms
{noformat}
Of course that I could be wrong, but now it seems to me that mentioned commit is the problem (it's not easy to profile such load).
> Performance regression comparing to previous release
> ----------------------------------------------------
>
> Key: AS7-6583
> URL: https://issues.jboss.org/browse/AS7-6583
> Project: Application Server 7
> Issue Type: Bug
> Components: CDI / Weld, Logging
> Affects Versions: 7.2.0.Alpha1
> Environment: 7.2.0.Final (prerelease-1 tag)
> Reporter: Tomas Remes
> Assignee: James Perkins
> Priority: Critical
> Labels: performance
>
> There is significant performance regression in 7.2.0 prerelease. I discovered it in my Weld performance load tests (testing simple Weld numberguess example application), but I am quite sure that's not Weld issue at all. I did some investigations and it seems that problem occurred in org/jboss/as/logging module.
--
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, 2 months
[JBoss JIRA] (AS7-6565) single jdbc driver deployed inside ear takes name of ear
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/AS7-6565?page=com.atlassian.jira.plugin.s... ]
Stefano Maestri updated AS7-6565:
---------------------------------
Summary: single jdbc driver deployed inside ear takes name of ear (was: jdbc driver deployed inside ear takes name of ear)
> single jdbc driver deployed inside ear takes name of ear
> --------------------------------------------------------
>
> Key: AS7-6565
> URL: https://issues.jboss.org/browse/AS7-6565
> Project: Application Server 7
> Issue Type: Feature Request
> Components: JCA
> Affects Versions: 7.1.1.Final, 8.0.0.Alpha1
> Reporter: Tom Eicher
> Assignee: Stefano Maestri
>
> We need to always give service name for jdbdriver as
> {code}
> deploymentUnit.getName() + "_" + driverClassName + "_" + majorVersion +"_" + minorVersion
> {code}
> even if thre is only one driver in the deployment unit. Current behavior is to give just deploymentUnit name in case of only one driver in. The changes makes more clear/readable driver names.
> Original description was:
> Including a JDBC driver, in this case PostgreSQL, in an ear like
> {code}
> myapp.ear:
> lib/postgresql-9.1-901.jdbc4.jar
> {code}
> does deploy the driver:
> {code}
> 23:37:28,118 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) JBAS010404: Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 9.1)
> {code}
> however the service name is not {{postgresql_9_1_901_jdbc4_jar}} as expected,
> but it's {{myapp_ear}}.
> (Seen in admin console, and this is the only value accepted in my -ds.xml file.)
> 1. JDBC driver service should pick name of innermost jar, not of containing ear
> 2. driver name (as to be used in datasource definition) should be logged with the log message above.
--
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, 2 months
[JBoss JIRA] (AS7-6567) Hang in ProfileTransformersTestCase ModelTestModelControllerService.waitForSetup
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/AS7-6567?page=com.atlassian.jira.plugin.s... ]
Kabir Khan commented on AS7-6567:
---------------------------------
Rebase and rebuild everything and the 7.2.0.Alpha1-SNAPSHOT should go away. This is the commit that does that: https://github.com/jbossas/jboss-as/commit/23237531bf850c44ecba5cb50151e7...
These test use maven repository artifacts to set up the classpath for the legacy controller, that is the intent.
If you still are seeing problems after a rebase and rebuild, then please let me know
> Hang in ProfileTransformersTestCase ModelTestModelControllerService.waitForSetup
> --------------------------------------------------------------------------------
>
> Key: AS7-6567
> URL: https://issues.jboss.org/browse/AS7-6567
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, Test Suite
> Reporter: Carlo de Wolf
> Assignee: Kabir Khan
> Attachments: AS7-6567-threaddump.txt
>
>
> {noformat}
> "main" prio=10 tid=0x00007fa1a8009000 nid=0x7f2 waiting on condition [0x00007fa1b1b13000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000007acdbe350> (a java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
> at org.jboss.as.model.test.ModelTestModelControllerService.waitForSetup(ModelTestModelControllerService.java:190)
> at org.jboss.as.core.model.test.AbstractKernelServicesImpl.create(AbstractKernelServicesImpl.java:108)
> at org.jboss.as.core.model.bridge.impl.ChildFirstClassLoaderKernelServicesFactory.create(ChildFirstClassLoaderKernelServicesFactory.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.as.core.model.bridge.local.ScopedKernelServicesBootstrap.createChildClassLoaderKernelServices(ScopedKernelServicesBootstrap.java:77)
> at org.jboss.as.core.model.bridge.local.ScopedKernelServicesBootstrap.createKernelServices(ScopedKernelServicesBootstrap.java:51)
> at org.jboss.as.core.model.test.CoreModelTestDelegate$LegacyKernelServicesInitializerImpl.install(CoreModelTestDelegate.java:565)
> at org.jboss.as.core.model.test.CoreModelTestDelegate$LegacyKernelServicesInitializerImpl.access$300(CoreModelTestDelegate.java:526)
> at org.jboss.as.core.model.test.CoreModelTestDelegate$KernelServicesBuilderImpl.build(CoreModelTestDelegate.java:493)
> at org.jboss.as.core.model.test.profile.ProfileTransformersTestCase.testProfilesTransformer(ProfileTransformersTestCase.java:66)
> {noformat}
--
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, 2 months
[JBoss JIRA] (DROOLS-47) Recovery from ChangeSet compilation fail
by Karel Cemus (JIRA)
[ https://issues.jboss.org/browse/DROOLS-47?page=com.atlassian.jira.plugin.... ]
Karel Cemus updated DROOLS-47:
------------------------------
Description:
Drools org.drools.compiler.PackageBuilder has a bug in loading change-sets containing damaged resources. Compilation of such change-set prevents builder recovery even by using undo() method.
When user adds new Drools resource into KnowledgeBuilder, its implementation KnowledgeBuilderImpl on line 50 calls PackageBuilder to register the change set file as an official resource.
In a following step the PackageBuilder extracts all mentioned resources from that change-set file and processes each of them separately but without their official registration in loaded resources. But these resources are processed under their own resource name which is the key in the set of reported errors.
Due to such behavior there remains errors preventing building stable org.drools.KnowledgeBase with an IllegalArgumentException even after calling KnowledgeBuilder#undo(), because it removes only errors reported directly with the change-set resource, but not the errors reported with resources from the change-set.
was:
Drools org.drools.compiler.PackageBuilder has a bug in loading damaged change-sets preventing its recovery using undo() method.
When user adds new Drools resource into KnowledgeBuilder, its implementation KnowledgeBuilderImpl on line 50 calls PackageBuilder to register the change set file as an official resource.
In a following step the PackageBuilder extracts all mentioned resources from that change-set file and processes each of them separately but without their official registration in loaded resources. But these resources are processed under their own resource name which is the key in the set of reported errors.
Due to such behavior there remains errors preventing building stable org.drools.KnowledgeBase with an IllegalArgumentException even after calling KnowledgeBuilder#undo(), because it removes only errors reported directly with the change-set resource, but not the errors reported with resources from the change-set.
> Recovery from ChangeSet compilation fail
> ----------------------------------------
>
> Key: DROOLS-47
> URL: https://issues.jboss.org/browse/DROOLS-47
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: Drools Expert 5.4.0, 5.5.0
> Reporter: Karel Cemus
> Assignee: Mark Proctor
> Priority: Minor
>
> Drools org.drools.compiler.PackageBuilder has a bug in loading change-sets containing damaged resources. Compilation of such change-set prevents builder recovery even by using undo() method.
> When user adds new Drools resource into KnowledgeBuilder, its implementation KnowledgeBuilderImpl on line 50 calls PackageBuilder to register the change set file as an official resource.
> In a following step the PackageBuilder extracts all mentioned resources from that change-set file and processes each of them separately but without their official registration in loaded resources. But these resources are processed under their own resource name which is the key in the set of reported errors.
> Due to such behavior there remains errors preventing building stable org.drools.KnowledgeBase with an IllegalArgumentException even after calling KnowledgeBuilder#undo(), because it removes only errors reported directly with the change-set resource, but not the errors reported with resources from the change-set.
--
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, 2 months
[JBoss JIRA] (DROOLS-47) Recovery from ChangeSet compilation fail
by Karel Cemus (JIRA)
Karel Cemus created DROOLS-47:
---------------------------------
Summary: Recovery from ChangeSet compilation fail
Key: DROOLS-47
URL: https://issues.jboss.org/browse/DROOLS-47
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: Drools Expert 5.4.0, 5.5.0
Reporter: Karel Cemus
Assignee: Mark Proctor
Priority: Minor
Drools org.drools.compiler.PackageBuilder has a bug in loading damaged change-sets preventing its recovery using undo() method.
When user adds new Drools resource into KnowledgeBuilder, its implementation KnowledgeBuilderImpl on line 50 calls PackageBuilder to register the change set file as an official resource.
In a following step the PackageBuilder extracts all mentioned resources from that change-set file and processes each of them separately but without their official registration in loaded resources. But these resources are processed under their own resource name which is the key in the set of reported errors.
Due to such behavior there remains errors preventing building stable org.drools.KnowledgeBase with an IllegalArgumentException even after calling KnowledgeBuilder#undo(), because it removes only errors reported directly with the change-set resource, but not the errors reported with resources from the change-set.
--
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, 2 months
[JBoss JIRA] (AS7-6565) jdbc driver deployed inside ear takes name of ear
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/AS7-6565?page=com.atlassian.jira.plugin.s... ]
Stefano Maestri updated AS7-6565:
---------------------------------
Description:
We need to always give service name for jdbdriver as
{code}
deploymentUnit.getName() + "_" + driverClassName + "_" + majorVersion +"_" + minorVersion
{code}
even if thre is only one driver in the deployment unit. Current behavior is to give just deploymentUnit name in case of only one driver in. The changes makes more clear/readable driver names.
Original description was:
Including a JDBC driver, in this case PostgreSQL, in an ear like
{code}
myapp.ear:
lib/postgresql-9.1-901.jdbc4.jar
{code}
does deploy the driver:
{code}
23:37:28,118 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) JBAS010404: Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 9.1)
{code}
however the service name is not {{postgresql_9_1_901_jdbc4_jar}} as expected,
but it's {{myapp_ear}}.
(Seen in admin console, and this is the only value accepted in my -ds.xml file.)
1. JDBC driver service should pick name of innermost jar, not of containing ear
2. driver name (as to be used in datasource definition) should be logged with the log message above.
was:
Including a JDBC driver, in this case PostgreSQL, in an ear like
{code}
myapp.ear:
lib/postgresql-9.1-901.jdbc4.jar
{code}
does deploy the driver:
{code}
23:37:28,118 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) JBAS010404: Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 9.1)
{code}
however the service name is not {{postgresql_9_1_901_jdbc4_jar}} as expected,
but it's {{myapp_ear}}.
(Seen in admin console, and this is the only value accepted in my -ds.xml file.)
1. JDBC driver service should pick name of innermost jar, not of containing ear
2. driver name (as to be used in datasource definition) should be logged with the log message above.
> jdbc driver deployed inside ear takes name of ear
> -------------------------------------------------
>
> Key: AS7-6565
> URL: https://issues.jboss.org/browse/AS7-6565
> Project: Application Server 7
> Issue Type: Feature Request
> Components: JCA
> Affects Versions: 7.1.1.Final, 8.0.0.Alpha1
> Reporter: Tom Eicher
> Assignee: Stefano Maestri
>
> We need to always give service name for jdbdriver as
> {code}
> deploymentUnit.getName() + "_" + driverClassName + "_" + majorVersion +"_" + minorVersion
> {code}
> even if thre is only one driver in the deployment unit. Current behavior is to give just deploymentUnit name in case of only one driver in. The changes makes more clear/readable driver names.
> Original description was:
> Including a JDBC driver, in this case PostgreSQL, in an ear like
> {code}
> myapp.ear:
> lib/postgresql-9.1-901.jdbc4.jar
> {code}
> does deploy the driver:
> {code}
> 23:37:28,118 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) JBAS010404: Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 9.1)
> {code}
> however the service name is not {{postgresql_9_1_901_jdbc4_jar}} as expected,
> but it's {{myapp_ear}}.
> (Seen in admin console, and this is the only value accepted in my -ds.xml file.)
> 1. JDBC driver service should pick name of innermost jar, not of containing ear
> 2. driver name (as to be used in datasource definition) should be logged with the log message above.
--
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, 2 months
[JBoss JIRA] (AS7-6565) jdbc driver deployed inside ear takes name of ear
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/AS7-6565?page=com.atlassian.jira.plugin.s... ]
Stefano Maestri edited comment on AS7-6565 at 2/21/13 5:30 AM:
---------------------------------------------------------------
Note also that the driver name have to be <deploymentUnitName> + driver name as postfix. It's because you coud have multiple ear deploying the same driver (jar name at least)
was (Author: maeste):
Note also that the drivere name have to be <deploymentUnitName> + driver name as postfix. It's because you coud have multiple ear deploying the same driver (jar name at least)
> jdbc driver deployed inside ear takes name of ear
> -------------------------------------------------
>
> Key: AS7-6565
> URL: https://issues.jboss.org/browse/AS7-6565
> Project: Application Server 7
> Issue Type: Feature Request
> Components: JCA
> Affects Versions: 7.1.1.Final, 8.0.0.Alpha1
> Reporter: Tom Eicher
> Assignee: Stefano Maestri
>
> Including a JDBC driver, in this case PostgreSQL, in an ear like
> {code}
> myapp.ear:
> lib/postgresql-9.1-901.jdbc4.jar
> {code}
> does deploy the driver:
> {code}
> 23:37:28,118 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) JBAS010404: Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 9.1)
> {code}
> however the service name is not {{postgresql_9_1_901_jdbc4_jar}} as expected,
> but it's {{myapp_ear}}.
> (Seen in admin console, and this is the only value accepted in my -ds.xml file.)
> 1. JDBC driver service should pick name of innermost jar, not of containing ear
> 2. driver name (as to be used in datasource definition) should be logged with the log message above.
--
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, 2 months
[JBoss JIRA] (AS7-6565) jdbc driver deployed inside ear takes name of ear
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/AS7-6565?page=com.atlassian.jira.plugin.s... ]
Stefano Maestri commented on AS7-6565:
--------------------------------------
Note also that the drivere name have to be <deploymentUnitName> + driver name as postfix. It's because you coud have multiple ear deploying the same driver (jar name at least)
> jdbc driver deployed inside ear takes name of ear
> -------------------------------------------------
>
> Key: AS7-6565
> URL: https://issues.jboss.org/browse/AS7-6565
> Project: Application Server 7
> Issue Type: Feature Request
> Components: JCA
> Affects Versions: 7.1.1.Final, 8.0.0.Alpha1
> Reporter: Tom Eicher
> Assignee: Stefano Maestri
>
> Including a JDBC driver, in this case PostgreSQL, in an ear like
> {code}
> myapp.ear:
> lib/postgresql-9.1-901.jdbc4.jar
> {code}
> does deploy the driver:
> {code}
> 23:37:28,118 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) JBAS010404: Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 9.1)
> {code}
> however the service name is not {{postgresql_9_1_901_jdbc4_jar}} as expected,
> but it's {{myapp_ear}}.
> (Seen in admin console, and this is the only value accepted in my -ds.xml file.)
> 1. JDBC driver service should pick name of innermost jar, not of containing ear
> 2. driver name (as to be used in datasource definition) should be logged with the log message above.
--
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, 2 months
[JBoss JIRA] (AS7-6583) Performance regression comparing to previous release
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/AS7-6583?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas commented on AS7-6583:
-------------------------------------
I just had a look in YJP and I am not seeing anything in logging (although I was just hitting the front page).
> Performance regression comparing to previous release
> ----------------------------------------------------
>
> Key: AS7-6583
> URL: https://issues.jboss.org/browse/AS7-6583
> Project: Application Server 7
> Issue Type: Bug
> Components: CDI / Weld, Logging
> Affects Versions: 7.2.0.Alpha1
> Environment: 7.2.0.Final (prerelease-1 tag)
> Reporter: Tomas Remes
> Assignee: James Perkins
> Priority: Critical
> Labels: performance
>
> There is significant performance regression in 7.2.0 prerelease. I discovered it in my Weld performance load tests (testing simple Weld numberguess example application), but I am quite sure that's not Weld issue at all. I did some investigations and it seems that problem occurred in org/jboss/as/logging module.
--
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, 2 months
[JBoss JIRA] (AS7-6565) jdbc driver deployed inside ear takes name of ear
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/AS7-6565?page=com.atlassian.jira.plugin.s... ]
Stefano Maestri updated AS7-6565:
---------------------------------
Issue Type: Feature Request (was: Bug)
> jdbc driver deployed inside ear takes name of ear
> -------------------------------------------------
>
> Key: AS7-6565
> URL: https://issues.jboss.org/browse/AS7-6565
> Project: Application Server 7
> Issue Type: Feature Request
> Components: JCA
> Affects Versions: 7.1.1.Final, 8.0.0.Alpha1
> Reporter: Tom Eicher
> Assignee: Stefano Maestri
>
> Including a JDBC driver, in this case PostgreSQL, in an ear like
> {code}
> myapp.ear:
> lib/postgresql-9.1-901.jdbc4.jar
> {code}
> does deploy the driver:
> {code}
> 23:37:28,118 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) JBAS010404: Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 9.1)
> {code}
> however the service name is not {{postgresql_9_1_901_jdbc4_jar}} as expected,
> but it's {{myapp_ear}}.
> (Seen in admin console, and this is the only value accepted in my -ds.xml file.)
> 1. JDBC driver service should pick name of innermost jar, not of containing ear
> 2. driver name (as to be used in datasource definition) should be logged with the log message above.
--
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, 2 months