[JBoss JIRA] (JBRULES-3352) Add the possibility to add an instance of Termination to the TerminationConfig
by Patrik Dufresne (JIRA)
Patrik Dufresne created JBRULES-3352:
----------------------------------------
Summary: Add the possibility to add an instance of Termination to the TerminationConfig
Key: JBRULES-3352
URL: https://issues.jboss.org/browse/JBRULES-3352
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-planner
Affects Versions: 5.3.1.Final
Environment: N/A
Reporter: Patrik Dufresne
Assignee: Geoffrey De Smet
The TerminationConfig class doesn't allow the user to sets a custom instance of a Termination. The only function available is to sets a Termination class using TerminationConfig.setTerminationClass(Class<Termination>). The user is then limited to provide a custom termination class that doesn't required any settings. (i.e.: it's not possible to have a Termination with a constructor requiring arguments)
I suggest to add a function similar to other configuration class. e.g.: TerminationConfig.setTermination(Termination) and TerminationConfig.getTermination()
--
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
[JBoss JIRA] (AS7-3355) Significant performance degradation while working with Entity beans
by Alexey Makhmutov (JIRA)
Alexey Makhmutov created AS7-3355:
-------------------------------------
Summary: Significant performance degradation while working with Entity beans
Key: AS7-3355
URL: https://issues.jboss.org/browse/AS7-3355
Project: Application Server 7
Issue Type: Bug
Components: EJB
Affects Versions: 7.1.0.Final
Environment: Solaris x86 box with single Xeon E5620 @ 2.4 GHz (4 cores in total)
Oracle HotSpot JDK 1.6.0_30, 32-bit Server VM
Standalone server configuration (JBoss AS 7.1.0.Final-SNAPSHOT)
JVM memory options: -Xms2048m -Xmx2048m -XX:NewSize=512m -XX:MaxNewSize=512m -XX:MaxPermSize=384m
Reporter: Alexey Makhmutov
Assignee: jaikiran pai
Attachments: jb51-gc.log, jb71-default-gc.log, jb71-pooled-gc.log, poolProblemTC.zip
We've run a series of performance tests on JBoss AS 7.1 (including latest nightly builds) and noticed a significant performance degradation while working with Entity EJBs under high load. Sample applications worked 2-5 times slower on 7.1 compared to 5.1 configuration. The most noticeable root cause for such results is related to garabage collector behavior on 7.1 - even minor GC pauses on 7.1 are much longer compared to 5.1 and amount of used memory in heap was also much higher. After looking on Java heap content, we've tracked the problem down to creation of EntityInstance object. As for now, AS 7.1 has no pool for entity beans (it's using InfinitePool, which actually creates new instance on every request). This results in huge amount of created EntityBeanComponentInstance objects. Every such object has non-trivial 'finalize' method, so it cannot be easily reclaimed by GC.
I'm attaching archive with the sample application and simple Apache JMeter load scenario which can demonstrate the problem. The application contains simple Entity EJB (no working with DB, just stub methods) and single JSP page, which starts transaction and touch specified number of entity beans (200 per transaction in our test). We've done test with current 7.1 implementation and using hacked AS version with attached MaxStrictPool instead of InfinitePool for EntityBeanComponent.
Here is the summary results for throughput of that sample application on tested environment (10 load threads, each request loads 200 entity beans, 50 ms wait time between requests):
|| Configuration || Throughput ||
| JBoss AS 5.1 | 133 req/s |
| JBoss AS 7.1 (default) | 66 req/s |
| JBoss AS 7.1 (with pooling) | 142,5 req/s |
Please, see also the GC logs collected during these runs. These results just illustrate the problem -- on some other case we've got even worse results (you can try to reduce the wait time between requests in order to reproduce them).
So, it seems that the observed performance degradation may be caused by missing of pooling implementation for entity beans in current 7.1 codebase.
--
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
[JBoss JIRA] Created: (JBAS-9349) Server startup message on console goes missing if a deployment fails during server startup
by jaikiran pai (JIRA)
Server startup message on console goes missing if a deployment fails during server startup
------------------------------------------------------------------------------------------
Key: JBAS-9349
URL: https://issues.jboss.org/browse/JBAS-9349
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: AS7 upstream dated April 19 2011
Reporter: jaikiran pai
Priority: Minor
Fix For: 7.0.0.Beta3
I placed a failing deployment (picked the .ear from JBAS-9261) in the standalone/deployments folder and started the standalone server. The server picked up the deployment during startup and threw a service missing dependency error but *did not* show the usual server started in xxx ms message. Here's the entire log:
{code}
14:02:49,540 INFO [org.jboss.as.deployment] (MSC service thread 1-4) Started FileSystemDeploymentService for directory /NotBackedUp/jpai/business/jboss/wc/jbossas/as7/jboss-as/build/target/jboss-7.0.0.Beta3-SNAPSHOT/standalone/deployments
14:02:49,592 INFO [org.jboss.as.jmx.JMXConnectorService] (MSC service thread 1-1) Starting remote JMX connector
14:02:49,633 INFO [org.jboss.as.server.deployment] (DeploymentScanner-threads - 1) Content added at location /NotBackedUp/jpai/business/jboss/wc/jbossas/as7/jboss-as/build/target/jboss-7.0.0.Beta3-SNAPSHOT/standalone/data/content/43/79aa12f1960aa376bf9cb259576498616f5a7c/content
14:02:49,636 INFO [org.jboss.remoting] (MSC service thread 1-4) JBoss Remoting version 3.1.0.Beta2
14:02:49,712 INFO [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-2) The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /opt/Java/SunJava-6/jdk1.6.0_21/jre/lib/i386/server:/opt/Java/SunJava-6/jdk1.6.0_21/jre/lib/i386:/opt/Java/SunJava-6/jdk1.6.0_21/jre/../lib/i386:/usr/java/packages/lib/i386:/lib:/usr/lib
14:02:49,879 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) Starting deployment of "Stateless.ear"
14:02:49,883 INFO [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-3) live server is starting..
14:02:49,980 WARN [org.jboss.vfs] (MSC service thread 1-1) VFS was unable to set the URLStreamHandlerFactory. This will have unpredictable results
14:02:50,022 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-2) Starting Coyote HTTP/1.1 on http-localhost-127.0.0.1-8080
14:02:50,114 INFO [org.jboss.as.connector] (MSC service thread 1-4) Starting JCA Subsystem (JBoss IronJacamar 1.0.0.Beta5)
14:02:50,123 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) Starting deployment of "StatelessWeb.war"
14:02:50,132 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) Starting deployment of "StatelessEJB.jar"
14:02:50,134 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) Starting deployment of "StatelessClient.jar"
14:02:50,145 WARN [org.jboss.as.server.deployment] (MSC service thread 1-1) Class Path entry StatelessEJB.jar in "/content/Stateless.ear/StatelessClient.jar" does not point to a valid jar for a Class-Path reference.
14:02:50,221 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) Bound JDBC Data-source [java:/H2DS]
14:02:50,435 INFO [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-3) Started Netty Acceptor version 3.2.1.Final-r2319 localhost:5455 for CORE protocol
14:02:50,436 INFO [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-3) Started Netty Acceptor version 3.2.1.Final-r2319 localhost:5445 for CORE protocol
14:02:50,438 INFO [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-3) HornetQ Server version 2.1.2.Final (Colmeia, 120) started
14:02:50,480 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC00001: Failed to start service jboss.deployment.subunit."Stateless.ear"."StatelessWeb.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."Stateless.ear"."StatelessWeb.war".INSTALL: Failed to process phase INSTALL of subdeployment "StatelessWeb.war" of deployment "Stateless.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:108)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_21]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
Caused by: java.lang.IllegalArgumentException: Cannot find source service for lookup name: KeksLocal
at org.jboss.as.ee.component.LookupBindingSourceDescription.<init>(LookupBindingSourceDescription.java:73)
at org.jboss.as.ejb3.deployment.processors.EjbRefProcessor.processDescriptorEntries(EjbRefProcessor.java:99)
at org.jboss.as.ee.component.AbstractDeploymentDescriptorBindingsProcessor.deploy(AbstractDeploymentDescriptorBindingsProcessor.java:57)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:102)
... 4 more
14:02:50,661 INFO [org.jboss.as.server] (MSC service thread 1-1) Service status report
New missing/unsatisfied dependencies:
service jboss.naming.context.java.module.Stateless.StatelessWeb (missing)
Services which failed to start:
service jboss.deployment.subunit."Stateless.ear"."StatelessWeb.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."Stateless.ear"."StatelessWeb.war".INSTALL: Failed to process phase INSTALL of subdeployment "StatelessWeb.war" of deployment "Stateless.ear"
{code}
Removing the failing deployment and restarting the server shows the server startup message:
{code}
14:08:33,603 INFO [org.jboss.as] (MSC service thread 1-2) JBoss AS 7.0.0.Beta3-SNAPSHOT "TBD" started in 3328ms - Started 99 of 123 services (24 services are passive or on-demand)
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] Created: (AS7-993) Remove noise from start/stop console log
by Max Rydahl Andersen (JIRA)
Remove noise from start/stop console log
----------------------------------------
Key: AS7-993
URL: https://issues.jboss.org/browse/AS7-993
Project: Application Server 7
Issue Type: Bug
Reporter: Max Rydahl Andersen
latest trunk still prints the following on Ctrl+C/Stop:
16:05:20,700 INFO [org.jboss.as.osgi] (MSC service thread 1-3) Stopping OSGi Framework
16:05:20,738 INFO [org.jboss.as.logging] Restored bootstrap log handlers
16:05:20,768 INFO [com.arjuna.ats.jbossatx] ARJUNA32018: Destroying TransactionManagerService
16:05:20,769 INFO [com.arjuna.ats.jbossatx] ARJUNA32014: Stopping transaction recovery manager
16:05:20,802 INFO [org.hornetq.core.server.impl.HornetQServerImpl] HornetQ Server version 2.2.2.Final (super-hornetq-fighter, 122) [0462442a-936a-11e0-ac45-001c42000009] stopped
16:05:20,805 INFO [org.jboss.as] JBoss AS 7.0.0.Beta4-SNAPSHOT "(TBD)" stopped in 102ms
Besides the last one why do we need to info log stopping of osgi, log handlers, arjuna and recovery managers and hornetq ?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[JBoss JIRA] (SECURITY-642) UsernamePasswordLM causes NPE in SecurityVaultUtil when user provides wrong username
by Stefan Guilhen (JIRA)
Stefan Guilhen created SECURITY-642:
---------------------------------------
Summary: UsernamePasswordLM causes NPE in SecurityVaultUtil when user provides wrong username
Key: SECURITY-642
URL: https://issues.jboss.org/browse/SECURITY-642
Project: PicketBox (JBoss Security and Identity Management)
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: PicketBox_v4_0_6.Beta2
Reporter: Stefan Guilhen
Assignee: Anil Saldhana
Fix For: PicketBox_v4_0_6
Application is protected by a security domain that uses the UsersRolesLoginModule. If the user attempts a login with the right username and wrong pw, the login fails and the message in the AS7 logs display the correct reason for auth failure. However, if the user supplies an username that has not been added to the users.properties file, the login fails and the AS7 logs display an NPE instead of the correct reason message:
15:33:37,622 ERROR [org.jboss.security.authentication.JBossCachedAuthenticationManager] (http--127.0.0.1-8080-1) Login failure: javax.security.auth.login.LoginException: java.lang.NullPointerException
at org.jboss.security.vault.SecurityVaultUtil.isVaultFormat(SecurityVaultUtil.java:59)
at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:250)
at org.jboss.security.auth.spi.UsersRolesLoginModule.login(UsersRolesLoginModule.java:155)
The relevant code in UsernamePasswordLoginModule is this:
String expectedPassword = getUsersPassword();
//Check if the password is vaultified
if(SecurityVaultUtil.isVaultFormat(expectedPassword))
{
try
{
expectedPassword = SecurityVaultUtil.getValueAsString(expectedPassword);
}
catch (SecurityVaultException e)
{
LoginException le = new LoginException(ErrorCodes.PROCESSING_FAILED + "Unable to get the password value from vault");
le.initCause(e);
throw le;
}
}
The problem occurs because getUsersPassword() returns null since the properties file doesn't have a property that matches the supplied username. We need to verify if the expectedPassword is null before calling the vault util or change the vault util method to check for a null param.
--
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