[JBoss JIRA] Created: (JBRULES-1308) getFactHandle with equality-based assert behavior
by Adam Lewandowski (JIRA)
getFactHandle with equality-based assert behavior
-------------------------------------------------
Key: JBRULES-1308
URL: http://jira.jboss.com/jira/browse/JBRULES-1308
Project: JBoss Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 4.0.3
Reporter: Adam Lewandowski
If I set my rule base to use equality-based assert behavior, I'm expecting to be able to use the getFactHandle(object) method to retrieve a previously asserted fact by providing an equivalent (by equals() and hashCode()) object as an argument. This appears to not be the case, as AbstractWorkingMemory uses it's identityMap and associated IdentityAssertMapComparator to do the getFactHandle lookup instead of the assertMap and EqualityAssertMapComparator. This causes the lookup to be done with the system hashCode() method and not the overridden version supplied in my fact class. The lookup thus fails and returns null.
See attached unit test.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years
[JBoss JIRA] Created: (JBCACHE-1252) problem is CacheStoreInterceptor
by Nadav Fried (JIRA)
problem is CacheStoreInterceptor
--------------------------------
Key: JBCACHE-1252
URL: http://jira.jboss.com/jira/browse/JBCACHE-1252
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 1.4.1.SP1
Environment: Linux 2.6.9-5.ELsmp, JBOSS 4.0.5GA
Reporter: Nadav Fried
Assigned To: Manik Surtani
Hi,
When running load on a 4 node clustered jboss(4.0.5.GA) environment, one of the nodes occassionaly goes out of memory.
When looking at the memory dump, i see alot of org.jgroup.Message objects. After inspecting their contents I'm pretty sure these objects are related to jboss cache. Also, in the stack trace I see that one thread is always stuck trying to write to a HashMap in CacheStoreInterceptor.
It seems that the HashMap is not synchronized. Here is the relevant stack trace part:
"MessageDispatcher up processing thread" daemon prio=10 tid=0x6a840000 nid=0x7a7c runnable [0x68cfe000..0x68cff040]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.put(HashMap.java:376)
at org.jboss.cache.interceptors.CacheStoreInterceptor.prepareCacheLoader(CacheStoreInterceptor.java:299)
at org.jboss.cache.interceptors.CacheStoreInterceptor.invoke(CacheStoreInterceptor.java:130)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.TxInterceptor.handleCommitRollback(TxInterceptor.java:660)
at org.jboss.cache.interceptors.TxInterceptor.runCommitPhase(TxInterceptor.java:702)
at org.jboss.cache.interceptors.TxInterceptor$RemoteSynchronizationHandler.afterCompletion(TxInterceptor.java:1007)
at org.jboss.cache.interceptors.OrderedSynchronizationHandler.afterCompletion(OrderedSynchronizationHandler.java:83)
at org.jboss.tm.TransactionImpl.doAfterCompletion(TransactionImpl.java:1526)
at org.jboss.tm.TransactionImpl.completeTransaction(TransactionImpl.java:1198)
at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:377)
at org.jboss.cache.interceptors.TxInterceptor.handlePessimisticPrepare(TxInterceptor.java:479)
at org.jboss.cache.interceptors.TxInterceptor.handleRemotePrepare(TxInterceptor.java:304)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:127)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183)
at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
at org.jboss.cache.TreeCache._replicate(TreeCache.java:4827)
at sun.reflect.GeneratedMethodAccessor117.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:236)
at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:220)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:615)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:512)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554)
at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691)
at java.lang.Thread.run(Thread.java:619)
Here is our configuration(same on all 4 nodes) - (I know it's still the old configuration style but still it should work):
<!-- ==================================================================== -->
<!-- Defines TreeCache configuration -->
<!-- ==================================================================== -->
<mbean code="org.jboss.cache.TreeCache"
name="MessagingAS:service=MASClusterCache">
<depends>jboss:service=Naming</depends>
<depends>jboss:service=TransactionManager</depends>
<!--
Configure the TransactionManager
-->
<attribute name="TransactionManagerLookupClass">org.jboss.cache.JBossTransactionManagerLookup</attribute>
<!--
Node locking level : SERIALIZABLE
REPEATABLE_READ (default)
READ_COMMITTED
READ_UNCOMMITTED
NONE
-->
<attribute name="CacheLoaderClass">org.jboss.cache.loader.FileCacheLoader</attribute>
<attribute name="CacheLoaderConfig" replace="false">location=/home/TEMP/jbossCache_poller</attribute>
<!-- this will be the default in the future (elih)
<attribute name="CacheLoaderConfig" replace="false">
location=/HOME/tmp
</attribute>
-->
<attribute name="IsolationLevel">READ_UNCOMMITTED</attribute>
<!--
Valid modes are LOCAL
REPL_ASYNC
REPL_SYNC
INVALIDATION_ASYNC
INVALIDATION_SYNC
-->
<attribute name="CacheMode">REPL_ASYNC</attribute>
<!-- Name of cluster. Needs to be the same for all clusters, in order
to find each other
-->
<attribute name="ClusterName">MASLOAD2</attribute>
<!-- JGroups protocol stack properties. Can also be a URL,
e.g. file:/home/bela/default.xml
<attribute name="ClusterProperties"></attribute>
-->
<attribute name="ClusterConfig">
<config>
<!-- UDP: if you have a multihomed machine,
set the bind_addr attribute to the appropriate NIC IP address -->
<!-- UDP: On Windows machines, because of the media sense feature
being broken with multicast (even after disabling media sense)
set the loopback attribute to true -->
<UDP mcast_addr="228.1.2.5" mcast_port="45577"
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="true"/>
<PING timeout="2000" num_initial_members="3"
up_thread="false" down_thread="false"/>
<MERGE2 min_interval="10000" max_interval="20000"/>
<FD timeout="10000" max_tries="5" shun="true" up_thread="true" down_thread="true"/>
<VERIFY_SUSPECT timeout="1500"
up_thread="false" down_thread="false"/>
<pbcast.NAKACK gc_lag="50" retransmit_timeout="600,1200,2400,4800"
up_thread="false" down_thread="false"/>
<pbcast.STABLE desired_avg_gossip="20000"
up_thread="false" down_thread="false"/>
<UNICAST timeout="600,1200,2400" window_size="100" min_threshold="10"
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="false" down_thread="false"/>
</config>
</attribute>
<!--
The max amount of time (in milliseconds) we wait until the
initial state (ie. the contents of the cache) are retrieved from
existing members in a clustered environment
-->
<attribute name="InitialStateRetrievalTimeout">20000</attribute>
<!--
Number of milliseconds to wait until all responses for a
synchronous call have been received.
-->
<attribute name="SyncReplTimeout">15000</attribute>
<!-- Max number of milliseconds to wait for a lock acquisition -->
<attribute name="LockAcquisitionTimeout">10000</attribute>
</mbean>
Thanks,
Nadav
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years
[JBoss JIRA] Created: (JBAS-4682) Web session passivation does very little with FIELD granularity
by Brian Stansberry (JIRA)
Web session passivation does very little with FIELD granularity
---------------------------------------------------------------
Key: JBAS-4682
URL: http://jira.jboss.com/jira/browse/JBAS-4682
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering, Web (Tomcat) service
Affects Versions: JBossAS-5.0.0.Beta2
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Passivation of clustered HttpSessions works by evicting the node tree representing a given session from the cache. Configuration is based on defining how many active (in-memory) sesssion are allowed and how old they can be before passivating them. Problem is, with FIELD replication, the bulk of the data associated with a session is not in that sessions's subtree; it's in the _JBossInternal_ area. Evicting the session's tree doesn't free up the memory associated with the POJOs.
Structure of data in JBC:
/JSESSION
+++ /localhost
++++++/webapp
+++++++++/session12345
+++++++++/session67890
+++++++++/_JBossInternal_
++++++++++++/pojoAAAAA
++++++++++++/pojoBBBBB
(Note: session passivation is not done using the regular JBC eviction algorithms, as JBC doesn't understand what a "session" is. The http session replication layer manages the passivation, just using the JBC evict() method to do the actual passivation.)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years
[JBoss JIRA] Created: (JBAS-5091) BuddyCommunicationTimeout is too low
by Brian Stansberry (JIRA)
BuddyCommunicationTimeout is too low
------------------------------------
Key: JBAS-5091
URL: http://jira.jboss.com/jira/browse/JBAS-5091
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering, EJB3, Web (Tomcat) service
Affects Versions: JBossAS-4.2.2.GA, JBossAS-5.0.0.Beta3
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: JBossAS-5.0.0.CR1, JBossAS-4.2.3.GA
The buddy communication timeout setting in jbossweb-cluster-beans.xml and ejb3-clustered-sfsbcache-beans.xml (as well as jbossweb-cluster.sar/META-INF/jboss-service.xml in the 4.x branches) is only 2 seconds. This value controls how long a node will wait for data gravitation responses, so 2 seconds is too low. Under load, data gravitation responses may not arrive within 2 seconds. Value should be made the same as SyncReplTimeout; more like 20 seconds.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years