July 2008 - jboss-user - Jboss List Archives

[JBoss Cache: Core Edition] - Re: JBoss Cache performance looks pretty poor :(

by phpguy99

That is the kind of advice I liked to hear. I may have missed it - but I don't recall reading about the proper way to spread objects into the tree to get maximum performance. Thanks. I'll modify the code and the configuration and download 2.2 beta and test it again. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166042#4166042 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166042

17 years, 9 months

1
0
0 / 0

[JBoss Cache: Core Edition] - Re: JBoss Cache performance looks pretty poor :(

by manik.surtani＠jboss.com

spreading your stuff across the tree structure will help. The node structure is maintained using a CHM per Node to hold references to its children. And these CHMs are tuned for a lower-than-normal memory footprint so this means having lots of children per node will hurt concurrency. I'd recommend not putting more than 50 children per node and going as deep as you have to. Also, re: your state retrieval, 20000 is pretty low (20 seconds) and if you have a lot of state, there is no way you will be able to transfer all that in 20 secs! :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166041#4166041 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166041

17 years, 9 months

1
0
0 / 0

[JBoss Cache: Core Edition] - Re: JBoss Cache performance looks pretty poor :(

by jason.greene＠jboss.com

You have to use the squary brackets with code since its bbcode see: http://en.wikipedia.org/wiki/BBCode BTW in addition to Manik's suggestions, you are also experiencing this bug (will be fixed in the next 2.2 release), which is why your memory usage is so high: http://jira.jboss.org/jira/browse/JBCACHE-1383 http://www.jboss.com/index.html?module=bb&op=viewtopic&t=138338 -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166039#4166039 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166039

17 years, 9 months

1
0
0 / 0

[JBoss Cache: Core Edition] - Re: JBoss Cache performance looks pretty poor :(

by phpguy99

That is why I place all my data into their own Fqn. I have 1,000,000 objects (Meters) and each of them is constructed using: Fqn fqn = new Fqn("root", "MeterID" + i); Node<Object,Object> node = rootNode.addChild(fqn); node.put("data", meter); Does it mean I *over* do it? Instead of using a sunshine structure (1 level), should I structure my objects to fit into something like radix-tree? The reason I'm using REPL_SYNC is to be fair to EHCache since I'm using SYNC, too, as well as Terracotta (write-lock). Thanks for the quick response :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166036#4166036 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166036

17 years, 9 months

1
0
0 / 0

[JBossWS] - standard BASIC AUTH

by sfisque

i am trying to deploy a pojo endpoint webservice facade to an ORM library in JBoss 4.2.2. on Solaris 10. i have the entities deploying fine, and the facades and webservice endpoint are deploying fine as well. all of this is in a .JAR file with no WEB-INF or other webapp kruft. i have been able to secure my web service using the JBoss proprietary annotations (SecurityDomain and WebContext) without much problem. my question is, is there a way to do a .JAR deployment (no WEB-INF/web.xml) that would allow me to secure the endpoint without using any proprietary annotations or linkages. i am hoping to create a deployment that is container agnostic if possible (i've been able to keep all the entity annotations limited to JPA standard ones, so far) TIA == stanton View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166032#4166032 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166032

17 years, 9 months

1
0
0 / 0

[JBoss Cache: Core Edition] - Re: JBoss Cache performance looks pretty poor :(

by manik.surtani＠jboss.com

Is all your data placed under the same Fqn? All locking and replication granularity happens on a per-Node (Fqn) basis. I would recommend making better use of the tree structure of the cache and spreading your state around a bit better. Also, if you don't need the atomicity guarantees of REPL_SYNC (and there is not much you can do with it if you don't use transactions anyway) you're better off using REPL_ASYNC. Cheers, Manik View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166031#4166031 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166031

17 years, 9 months

1
0
0 / 0

[JBoss Cache: Core Edition] - Re: JBoss Cache performance looks pretty poor :(

by phpguy99

I'm using: CacheMode=REPL_SYNC IsolationLevel=READ_COMMITTED LockParentForChildInsertRemove=false StateRetrievalTimeout=20000 SyncReplTimeout=20000= LockAcquisitionTimeout=15000 I put each of my object into a Fqn. So the ROOT has 1,000,000 direct children. jdk: 1.6.0_07 OS: RHEL 5.1 on 8 cores Xeon all my nodes are on the same subnet (and same switch). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166030#4166030 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166030

17 years, 9 months

1
0
0 / 0

[JBoss Cache: Core Edition] - Re: JBoss Cache performance looks pretty poor :(

by phpguy99

Reposting my config again now with code-tag: <?xml version="1.0" encoding="UTF-8"?> jboss:service=Naming jboss:service=TransactionManager org.jboss.cache.transaction.GenericTransactionManagerLookup READ_COMMITTED false REPL_SYNC JBossCache-Cluster <UDP mcast_addr="228.1.2.3" mcast_port="48866" ip_ttl="64" ip_mcast="true" mcast_send_buf_size="150000" mcast_recv_buf_size="80000" ucast_send_buf_size="150000" ucast_recv_buf_size="80000" loopback="false"/> <PING timeout="2000" num_initial_members="3"/> <MERGE2 min_interval="10000" max_interval="20000"/> <FD_SOCK/> <VERIFY_SUSPECT timeout="1500"/> <pbcast.NAKACK gc_lag="50" retransmit_timeout="600,1200,2400,4800" /> <pbcast.STABLE desired_avg_gossip="400000"/> <FC max_credits="2000000" min_threshold="0.10"/> <FRAG2 frag_size="8192"/> <pbcast.GMS join_timeout="5000" shun="true" print_local_addr="true"/> <pbcast.STATE_TRANSFER/> 20000 20000 15000 $ jmap -histo 14359 ## for 200,000 of my object in the cache. num #instances #bytes class name ---------------------------------------------- 1: 6058302 290798496 java.util.concurrent.locks.ReentrantLock$NonfairSync 2: 6058260 290796480 java.util.concurrent.ConcurrentHashMap$Segment 3: 6058260 198060352 [Ljava.util.concurrent.ConcurrentHashMap$HashEntry; 4: 379178 57632968 [Ljava.util.HashMap$Entry; 5: 378642 57553488 [Ljava.util.concurrent.ConcurrentHashMap$Segment; 6: 765551 57436024 [C 7: 378601 33316888 org.jboss.cache.UnversionedNode 8: 763508 30540320 java.lang.String 9: 378601 30288080 org.jboss.cache.invocation.NodeInvocationDelegate 10: 378642 27262224 java.util.concurrent.ConcurrentHashMap 11: 378600 27259200 org.jboss.cache.lock.NonBlockingWriterLock 12: 379058 24259712 java.util.HashMap 13: 383949 18429552 java.util.concurrent.ConcurrentHashMap$HashEntry 14: 379889 18234672 java.util.HashMap$Entry 15: 378600 18172800 org.jboss.cache.lock.IdentityLock 16: 396538 15881688 [Ljava.lang.Object; 17: 384436 15377440 java.util.ArrayList 18: 381480 15259200 org.jboss.cache.Fqn 19: 378599 15143960 com.ssn.jbosscache.Meter 20: 378600 12115200 org.jboss.cache.lock.LockMap 21: 378600 9086400 org.jboss.cache.lock.ReadWriteLockWithUpgrade$WriterLock 22: 378600 9086400 org.jboss.cache.lock.ReadWriteLockWithUpgrade$ReaderLock 23: 378600 9086400 org.jboss.cache.util.concurrent.ConcurrentHashSet 24: 378600 9086400 org.jboss.cache.lock.LockStrategyReadCommitted 25: 21274 2804184 26: 21274 2560560 27: 1838 2036776 28: 33111 1620128 29: 1838 1356816 30: 1612 1315584 31: 2919 552944 [I 32: 2123 544336 [B 33: 2989 454328 java.lang.reflect.Method 34: 2008 369472 java.lang.Class View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166028#4166028 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166028

17 years, 9 months

1
0
0 / 0

[JBoss Cache: Core Edition] - Re: JBoss Cache performance looks pretty poor :(

by jason.greene＠jboss.com

Also could you tell us about your EHCache config, where you using asynchronous replication for example? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166025#4166025 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166025

17 years, 9 months

1
0
0 / 0

[JBoss jBPM] - Re: jBPM versus MS Workflow

by kukeltje

Uhm.... my personal comments - .NET 3.5 is stable, just like jBPM 3.2.3 is stable... or JDK 1.5.0_02 is stable. If you would have said .NET is stable, then it is a different thing (4 releases in?). The jBPM API has not changed that much in the last 2 years, so I'd say it is quite stable. >From your statement I cannot determine where persistence and thread synchronization (aren't they two only partly related things?) are more robust in MS Workflow then in jBPM. The latter uses Hibernate which is really robust. The relation with Rich Clients is totally unclear to me, since jBPM can be used in stand-alone, pure web or rich client implementations. If you could elaborate a little more, I can try to comment. Comparing the MS Workflow 'platform' to jBPM is imo comparing apples to grapes (not even oranges). I think you should include SEAM, JBossTools etc... to have a real comparison (I do not know the details of MS Workflow) So even with my basic knowledge of MS Workflow, I have to say you statement of 'superiour' is a bold statement and needs more detailed arguments (yes, I'm biased, but I get the feeling you are to ;-) ) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166022#4166022 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166022

17 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-user July 2008