I'm currently doing load tests on a old JBoss AS 6.1.
But I have the problem that the EJB3 pool seems to be limited to 50.
In the JMX Console is see :
CreateCount 50
CurrentSize 50
RemoveCount 0
MaxSize 50
InvocationStatistics
concurrentCalls='48' method name='applyRegulator' count='1902' minTime='108' maxTime='5825' totalTime='1874001'
What's strange is that I can add the #Pool annotation or change the pool size in ejb3-interceptors-aop.xml but it still limits at 50.
Have you increased the number of JMS sessions available?
#ActivationConfigProperty(propertyName = "maxSession", propertyValue="30")
If you instance pool is not being filled, then you are most likely running out of JMS sessions.
The EJB 3 connector is configured in ejb3-connectors-jboss-beans.xml, not remoting-jboss-beans.xml or any other file!
socket://${hostforurl}:${port}?timeout=300000&maxPoolSize=3000&clientMaxPoolSize=500
Source: https://developer.jboss.org/message/615825#615825
Related
Using
JBoss 7.1.0 EAP
Infinispan 8.2.8.Final-redhat-1
Is it possible to use passivation and memory based evictions with infinispan?
When I try to use this configuration:
ConfigurationBuilder config = new ConfigurationBuilder();
config.clustering().cacheMode(CacheMode.DIST_SYNC);
config.eviction()
.type(EvictionType.MEMORY)
.size(heapAllocationForCache);
config.persistence().passivation(true)
.addSingleFileStore()
.location("/path/to/cache-dir")
.purgeOnStartup(true);
When I try this configuration I get this error:
2019-10-30 11:28:59 INFO [] EvictionConfigurationBuilder:114 - ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
Here is the validation logic:
if (!strategy.isEnabled()) {
if (maxEntries > 0) {
strategy(EvictionStrategy.LIRS);
log.debugf("Max entries configured (%d) without eviction strategy. Eviction strategy overriden to %s", maxEntries, strategy);
} else if (getBuilder().persistence().passivation() && strategy != EvictionStrategy.MANUAL) {
log.passivationWithoutEviction(); // <--------- this line is where the warning comes from
}
}
Can you not use memory based eviction with Passivation? Or is this a bug with the validation on Infinispan 8.2.x?
Note we cannot set
strategy(EvictionStrategy.LRU) etc because of this code:
https://github.com/infinispan/infinispan/blob/8.2.11.Final/core/src/main/java/org/infinispan/configuration/cache/EvictionConfigurationBuilder.java
if (strategy.isEnabled() && maxEntries <= 0)
throw new CacheConfigurationException("Eviction maxEntries value cannot be less than or equal to zero if eviction is enabled");
As you use EAP the I would not use the Infinispan bits inside of EAP as this are not meant to be used for application cache - also you can not update the version as this is not supported.
Best approach is to use RHDG as a supported product or (if you can't) use the latest Infinispan version to have a full feature set and the latest fixes.
Also with 9.x yuo can use off-heap memory which provide often a better performance.
See this post for more details Unable to use Infinispan embedded cachemanager on JBoss EAP 7.2
You should be able to. The problem though is that in 8.2 the default strategy is NONE [1]. Setting the strategy to LIRS or LRU should fix your issue. Newer versions of Infinispan this setting is no longer required unless you want to set it to MANUAL eviction strategy.
config.eviction()
.type(EvictionType.MEMORY)
.strategy(EvictionStrategy.LRU)
.size(heapAllocationForCache);
[1] https://github.com/infinispan/infinispan/blob/8.2.x/core/src/main/java/org/infinispan/configuration/cache/EvictionConfiguration.java#L19
I have a Camel application deployed on JBoss in a WAR file with a spring configuration for starting the Camel context.
It deploys and runs very nicely on a JBoss EAP 7.0.0.GA.
If I want to change values in a property file that my application depends on and touch the war file, it normally redeploys the application. But in some cases it fails.
I get the following in the server.log:
2017-07-25 12:05:26.671 INFO class=org.apache.camel.impl.DefaultShutdownStrategy thread="ServerService Thread Pool -- 74" Starting to graceful shutdown 12 routes (timeout 300 seconds)
2017-07-25 12:05:26.725 INFO class=org.apache.camel.impl.DefaultShutdownStrategy thread="Camel (interfacedb) thread #2 - ShutdownTask" Waiting as there are still 4 inflight and pending exchanges to complete, timeout in 300 seconds. Inflights per route: [interfacePersistDirect = 1, route1 = 1, pullFromTransferEntityTable = 1, lastScheduledRun = 1]
...
2017-07-25 12:10:26.691 WARN class=org.apache.camel.impl.DefaultShutdownStrategy thread="ServerService Thread Pool -- 74" Timeout occurred during graceful shutdown. Forcing the routes to be shutdown now. Notice: some resources may still be running as graceful shutdown did not complete successfully.
2017-07-25 12:10:26.691 WARN class=org.apache.camel.impl.DefaultShutdownStrategy thread="Camel (interfacedb) thread #2 - ShutdownTask" Interrupted while waiting during graceful shutdown, will force shutdown now.
2017-07-25 12:10:26.694 INFO class=org.apache.camel.impl.DefaultShutdownStrategy thread="ServerService Thread Pool -- 74" Graceful shutdown of 12 routes completed in 300 seconds
After this the application will not start again. JBoss reports the following in the myApp.war.failed file in the deployments folder.
"WFLYDS0022: Did not receive a response to the deployment operation within the allowed timeout period [600 seconds]. Check the server configuration file and the server logs to find more about the status of the deployment."
The application normally deploys a lot quicker than 600 seconds. I can touch the war file or delete the .failed file, which normally triggers a redeployment, but JBoss keeps giving me the error above in the .failed file.
The application starts normally if I restart the JBoss VM, but I would like to avoid restarting the other applications running on the JBoss instance.
Any suggestions?
I installed an IBM WorkLight Server 6.2 20150129 on a WAS 8.5.5.2 ND on a Windows 2008 DataCenter VM with 4GB ram
min heap:512mb, max heap: 1536mb
I am deploying a *-all.wlapp of around 140mb and following error occurrs.
deploying an app of < 20mb is fine.
server1_exception.log
com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS
server1_(very long meaningless text).txt
[2/11/15 7:10:54:960 PST] FFDC Exception:javax.naming.ConfigurationException SourceId:com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS ProbeId:537 Reporter:java.lang.Class#e712aad3
javax.naming.ConfigurationException: A JNDI operation on a "java:" name cannot be completed because the server runtime is not able to associate the operation's thread with any J2EE application component. This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request. Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application. Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names. [Root exception is javax.naming.NameNotFoundException: Name "comp/env/ibm.worklight.admin.lockTimeoutInMillis" not found in context "java:".]
at com.ibm.ws.naming.java.javaURLContextImpl.throwExceptionIfDefaultJavaNS(javaURLContextImpl.java:522)
at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:552)
at com.ibm.ws.naming.java.javaURLContextImpl.lookupExt(javaURLContextImpl.java:481)
at com.ibm.ws.naming.java.javaURLContextRoot.lookupExt(javaURLContextRoot.java:485)
at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:370)
at org.apache.aries.jndi.DelegateContext.lookup(DelegateContext.java:161)
at javax.naming.InitialContext.lookup(InitialContext.java:436)
at com.ibm.worklight.admin.common.util.ContextPropertyUtil.getContextProperty(ContextPropertyUtil.java:184)
at com.ibm.worklight.admin.common.util.ContextPropertyUtil.getContextProperty(ContextPropertyUtil.java:164)
at com.ibm.worklight.admin.common.util.ContextPropertyUtil.getContextProperty(ContextPropertyUtil.java:65)
at com.ibm.worklight.admin.common.util.ContextPropertyUtil.getContextPropertyAsLong(ContextPropertyUtil.java:300)
at com.ibm.worklight.admin.actions.BaseCommitable.getLockTimeOutInMillis(BaseCommitable.java:415)
at com.ibm.worklight.admin.actions.CleanUnfinishedTransaction.cleanUnfinishedTransaction(CleanUnfinishedTransaction.java:94)
at com.ibm.worklight.admin.actions.BaseTransaction.internalRun(BaseTransaction.java:284)
at com.ibm.worklight.admin.actions.BaseTransaction$1.run(BaseTransaction.java:210)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:906)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:929)
at java.lang.Thread.run(Thread.java:796)
Caused by: javax.naming.NameNotFoundException: Name "comp/env/ibm.worklight.admin.lockTimeoutInMillis" not found in context "java:".
at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1228)
at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:1141)
at com.ibm.ws.naming.urlbase.UrlContextImpl.lookupExt(UrlContextImpl.java:1436)
at com.ibm.ws.naming.java.javaURLContextImpl.lookupExt(javaURLContextImpl.java:477)
... 15 more
In Microsoft IIS there is an attribute that controls this filesize limit. This attribute is called maxAllowedContentLength and it can be found in the <requestLimits> element of the IIS configuration file. Its default value is 30 000 000 bytes.
You should increase it to a filesize tha will contain the wlapp's filesize.
Uninstalled WAS 8.5.5.2 patch in IBM installation Manager to roll back to WAS 8.5.5.0 and restarted everything, then i can deploy adapters.
Does anyone know what the default value is of the max pool size within the -ds.xml file? As you can see below we only have minimum set to 0 with no entry for maxium. I'm worried the vendor who configured this was thinking no maximum entry means unlimited. Im wondering if no entry takes the default value Jboss assigns. I'm not sure what that value is.
Reason i'm concerned is because I'm getting this error:
Njavax.transaction.TransactionRolledbackException: Error obtaining connection: org.jboss.util.NestedSQLException: No ManagedConnections available within configured blocking timeout ( 30000 [ms] ); - nested throwable: (javax.resource.ResourceException: No ManagedConnections available within configured blocking timeout ( 30000 [ms] ));
My -ds.xml file
datasources>
<local-tx-datasource>
<jndi-name>SabaSite</jndi-name>
<connection-url>saba:jdbc:JSQLConnect://********/database=######/asciiStringParameters=false</connection-url>
<driver-class>com.saba.mssql.SabaJNETMSSQLDatabaseDriver</driver-class>
<min-pool-size>0</min-pool-size>
<exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
</local-tx-datasource>
</datasources>
Thanks,
Justin
You can check actual datasource properties yourself with help of JMX Console.
See How to check datasource in JBoss?
We've recently started seeing spikes in the thread counts on our tomcat servers (peaking at over 1000 when normally at around 100). We performed a thread dump on one of the tomcat servers whilst it's thread count was high and found that a large number of the threads were waiting on MultiThreadedHttpConnectionManager$ConnectionPool, stack trace as follows:
"TP-Processor21700" daemon prio=10 tid=0x4a0b3400 nid=0x2091 in Object.wait() [0x399f3000..0x399f4004]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x58ee5030> (a org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$ConnectionPool)
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.doGetConnection(MultiThreadedHttpConnectionManager.java:518)
- locked <0x58ee5030> (a org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$ConnectionPool)
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.getConnectionWithTimeout(MultiThreadedHttpConnectionManager.java:416)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:153)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
...
There are 3 points in our code where httpClient.executeMethod() is called (to obtain info via an http request to another tomcat server). In each case the GetMethod object passed to it has had its socket timeout value set (i.e. via getMethod.getParams().setSoTimeout();) before hand, and the MultiThreadedConnectionManager is configured in spring to have a connectionTimeout value of 10 seconds. One thing I have noticed is that only 2 of the 3 httpClient.executeMethod() invocations are followed by a call to getMethod.releaseConnection(), so I'm wondering if this may be the cause of the problem (i.e. connections not being explicitly released). However what's strange is that
the problem has only started occurring in the last few days and the source code has not been modified for over a year, plus the fact that there has been no recent surge in requests coming through to the tomcat servers. One change that did occur a couple of days before the problem started to occur was that we upgraded the JVM used by the tomcat server from Java 5 (1.5 update 14) to Java 6 (1.6 update 25). We have tried temporarily reverting the JVM version to Java 5 to see if the problem stopped occurring but it did not. Another point to note is that in most cases the tomcat server eventually recovers and
the thread count drops back to normal - we've only had one instance where a tomcat process appears to have crashed because of the thread count increase.
We are running Tomcat 5.5 with commons-httpclient-3.1.jar running against a Java 1.6 update 25 on a Red Hat linux environment.
Please let me know if you can suggest any ideas as to what may be the cause of this issue.
Thanks.
The problem was indeed caused by the fact that only 2 of the 3 httpClient.executeMethod(getMethod) invocations were followed by a call to getMethod.releaseConnection(). Ensuring all 3 httpClient.executeMethod(getMethod) invocations were inside a try/catch block followed by a finally block containing a call to getMethod.releaseConnection() prevented the high thread counts from occurring. Although this code had been in our live system for over a year, it appears that the reason the high thread count issue only recently started occurring was because various search engine crawlers had started hitting the site with lots of URL requests that caused the code where the connection was being used but not subsequently released to execute. Problem solved.