[JBoss Cache: Core Edition] - guidelines for tuning MVCC's concurrencyLevel?
by dukehoops
We're loading the following system:
Hibernate 3.3.1.GA
JBC 3.0.3.GA w/ invalidation_async as Transactional 2nd level cache (MVCC)
JBossTM JTA 4.6.0.GA
Tomcat 6 NIO
sun JVM 1.6
Cache's read/write ratio is around 100:1
We're noticing the following problems:
1. heap consumption much higher than expected
2. average latency increases at the same rate as # of concurrent users (not much scale)
I wonder whether #2 is affected by concurrencyLevel, currently set at 1000. If I understand correctly, increasing concurrencyLevel should decrease chances of lock contention and lock waiting times at the expense of memory. Correct? (our lockAcquisitionTimeout is set to 500ms, we retry tx up to 3 times on TimeoutException)
If so,
- is there a way to track average time spent waiting to acquire a lock?
- is there a way to track percentage of lock acquisition attempts that have to wait at all?
- are locks released at the end of Invocation or Transaction?
- any guesstimate of memory/other implication is concurrencyLevel were to be changed from 1000 to 10000?
Any other hints on tuning JBC3/Hibernate perf @ concurrency?
thanks
-nikita
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224424#4224424
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224424
17 years
[Installation, Configuration & DEPLOYMENT] - HTTP Status 400 - Invalid direct reference to form login pag
by JohnJoe
Hi evreybody,
I need your help!
I'm trying to integrate OpenKM, a jboss-based application, behind a revese-proxy managing SSO forward (i.e: manages users authentication once time and propagates authentication on secured applications).
Here are some indications:
OpenKM form login is composed of two fields :
- one for username, j_username
- one for password, j_password
(- and one submit button with "Login" as default value)
OpenKM form login action is /OpenKM/j_security_check
Of course, direct login (i.e. without passing through reverse-proxy) works fine.
Suppose I'm a trusted user (X.509 certificates checking validated) who is trying to connect to https://openkm.mycompany.com. Reverse-proxy authenticates me and then send itself my login/password for to protected OpenKM back-end sever, for example: john/doo.
This last operation consits to send from the reverse-proxy a POST request to /OpenKM/j_security_check with j_username=john&j_password=doo&submit=Login
Unfortunately reverse-proxy receives the following error:
HTTP Status 400 - Invalid direct reference to form login page
Then reverse-proxy is redirected to the authentication page. However authentication has succeeded since if I reload the authentication page (this one where I've been redirected) I'm redirected to OpenKM user interface and OpenKM works finally fine. (I hope I'm clear...)
I ensure you I've got other secured applications behing the reverse proxy which work fine.
So my questions are:
- how to disable this behavior? Is there the possibility to fix my problem?
- If yes, what files have to edit? With what parameters? (...)
I thank you in advance for your help.
Regards,
John.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224412#4224412
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224412
17 years
[JBoss Cache: Core Edition] - JDBC Cache Loader always loads from DB
by karnivas
I'm using JBoss Cache 1.4.1 SP8 and JGroups 2.4.1 SP4
I've configured my cache with JDBC Cacheloader and I see that for each request the cache is loading from the DB inspite of the data residing in the cache.
At what circumstances this might happen. The configuration i've used is
| <?xml version="1.0" encoding="UTF-8"?>
|
| <server>
|
| <classpath codebase="./lib" archives="jboss-cache.jar, jgroups.jar"/>
|
| <mbean code="org.jboss.cache.TreeCache"
| name="jboss.cache:service=TreeCache">
|
| <depends>jboss:service=Naming</depends>
| <depends>jboss:service=TransactionManager</depends>
|
| <attribute name="NodeLockingScheme">PESSIMISTIC</attribute>
|
| <attribute name="IsolationLevel">READ_COMMITTED</attribute>
|
| <attribute name="CacheMode">REPL_SYNC</attribute>
|
| <attribute name="UseInterceptorMbeans">true</attribute>
|
| <attribute name="UseReplQueue">false</attribute>
|
| <attribute name="ReplQueueInterval">0</attribute>
|
| <attribute name="ReplQueueMaxElements">0</attribute>
|
| <attribute name="ClusterName">Cache-LABS</attribute>
|
| <attribute name="FetchInMemoryState">true</attribute>
|
| <attribute name="ClusterConfig">
| <config>
| <UDP mcast_addr="224.40.50.60" mcast_port="49977"
| ip_ttl="64" ip_mcast="true"
| mcast_send_buf_size="150000" mcast_recv_buf_size="200000"
| ucast_send_buf_size="150000" ucast_recv_buf_size="200000"
| loopback="false" bind_addr="114.94.99.351"/>
| <PING timeout="2000" num_initial_members="3"
| up_thread="false" down_thread="false"/>
| <MERGE2 min_interval="10000" max_interval="20000"/>
| <FD shun="true" up_thread="true" down_thread="true" />
| <FD_SOCK/>
| <VERIFY_SUSPECT timeout="1500"
| up_thread="false" down_thread="false"/>
| <pbcast.NAKACK gc_lag="50" retransmit_timeout="600,1200,2400,4800"
| max_xmit_size="8192" up_thread="false" down_thread="false" discard_delivered_msgs="true"/>
| <UNICAST timeout="600,1200,2400" window_size="100" min_threshold="10"
| down_thread="false"/>
| <pbcast.STABLE desired_avg_gossip="20000"
| up_thread="false" down_thread="false"/>
| <FRAG frag_size="8192"
| down_thread="false" up_thread="false"/>
| <pbcast.GMS join_timeout="5000" join_retry_timeout="2000"
| shun="true" print_local_addr="true"/>
| <pbcast.STATE_TRANSFER up_thread="true" down_thread="true"/>
| </config>
| </attribute>
|
| <attribute name="SyncReplTimeout">150000</attribute>
|
| <attribute name="LockAcquisitionTimeout">120000</attribute>
|
| <attribute name="CacheLoaderConfiguration">
| <config>
| <passivation>false</passivation>
| <preload>/</preload>
| <shared>true</shared>
| <cacheloader>
| <class>org.jboss.cache.loader.JDBCCacheLoader</class>
| <properties>
| cache.jdbc.table.name=DBCACHE
| cache.jdbc.table.create=false
| cache.jdbc.table.drop=false
| cache.jdbc.table.primarykey=jbosscache_pk
| cache.jdbc.fqn.column=fqn
| cache.jdbc.fqn.type=varchar(255)
| cache.jdbc.node.column=node
| cache.jdbc.node.type=blob
| cache.jdbc.parent.column=parent
| cache.jdbc.datasource=jdbc/basic
| cache.async.batchSize=10000
| cache.async.pollWait=100
| cache.async.returnOld=true
| cache.async.queueSize=100
| cache.async.put=true
| </properties>
| <async>false</async>
| <fetchPersistentState>true</fetchPersistentState>
| <ignoreModifications>false</ignoreModifications>
| <purgeOnStartup>false</purgeOnStartup>
| </cacheloader>
| </config>
| </attribute>
|
| <attribute name="EvictionPolicyClass"></attribute>
|
| </mbean>
|
| </server>
|
The log messages from jboss are as
org.jboss.cache.loader.JDBCCacheLoader --> executing sql: select node from DBCACHE where fqn=?
Please suggest your thoughts on this.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224411#4224411
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224411
17 years