[JBoss JIRA] Commented: (JBAS-1436) Improved management
by Robert Klemme (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1436?page=comments#action_12393418 ]
Robert Klemme commented on JBAS-1436:
-------------------------------------
While looking for a way to get wait times for connections logged I stumbled across this one. From the activity log it's unclear to me whether there is actually work in progress besides PreparedStatementPool. Is there a chance that we will be able to see logging of how long a thread waited for a connection in JB 4.2.0? I looked at InternalManagedConnectionPool but it seems there is logging of wait time only in case the thread is interrupted (via the exception) but not in the standard case.
> Improved management
> -------------------
>
> Key: JBAS-1436
> URL: http://jira.jboss.com/jira/browse/JBAS-1436
> Project: JBoss Application Server
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: JCA service
> Reporter: Adrian Brock
> Assigned To: Weston Price
> Priority: Minor
>
> Forum Discussion Thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=48682
> **This is a holder issue. Each section should be raised as a new issue as it is
> developed with a link from this issue.**
> There are a number of areas in JCA that need better management capabilities.
> Some of these stats may also reveal the need for new configuration/tuning parameters.
> In core JCA:
> 1) Better visibility on the ManagedConnectionFactory.
> This is currently a DynamicMBean that provides basic config parameters, but we could also
> provide a proxy/wrapper to provide statistics of operations on the factory and its
> ManagedConnections.
> a) createManagedConnections
> b) matchManagedConnections
> c) events on from the listeners
> 2) Better visibility of the Pool(s)
> Only top level statistics are provided (you cannot see the subpools).
> The statistics are also not synchronized with the pool (for performance reasons
> and also the fact that each stat is retrieved on individual MBean getAttribute requests)
> Additional statistics could include wait times when requests are waiting on an empty pool,
> idle time of unused connections, etc.
> 3) Better visibility of the ConnectionManager
> Currently this has no visibility for management.
> Its main responsibilties are transactions enlistment and security.
> e.g. This could show how long is wasted because <track-connection-by-tx/> does not
> return the connection the pool until transaction completion.
> 4) JDBC resource adapter
> PreparedStatementCache stats
> Query time stats
> etc.
> 5) JMS resource adapter
> Message send/receive stats
> 6) Inbound messaging
> Stats for message delivery
> 7) Transaction inflow
> Stats for transaction inflow and also display a list of current inbound transactions
> 8) Work management
> Stats for the work management pools and timers
--
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
18 years, 6 months
[JBoss JIRA] Updated: (JBAS-1483) Non-clustering testing for clustered http session code
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1483?page=all ]
Brian Stansberry updated JBAS-1483:
-----------------------------------
Summary: Non-clustering testing for clustered http session code (was: Black box testing for http session (with and without replication))
Description:
We need to have more black box testing for http requests without replication. Every feature in single node should also be supported by the clustered session manager and session classes. But currently, our testsuite largely only covers the clustered aspects.
So here is two main steps:
1. Create an automated black box testing suite for http session request in a single node. We can use some tool to do this. Question is we need to define the tests.
2. Currently, Tomcat has a whole suite of unit testing on http session. We should look into that to see if we can re-use some of it in our own Tomcat module.
was:
While talking with Ivelin, I think we need to have more black box testing for http requests with and without replication. Every feature in single node should also be supported bu clustering, plus some additional use caes for clustering failover. But currently, I only have limited unit test case for clustering in term of failing over.
So here is two main steps:
1. Create an automated black box testing suite for http session request in a single node. We can use some tool to do this. Question is we need to define the tests.
2. Currently, Tomcat has a whole suite of unit testing on http session. We should look into that to see if we can re-use some of it in our own Tomcat module.
3. Create test cases for fail-over. I can help to define the set here.
Assignee: Brian Stansberry
Updated this to focus on the standalone use case testing. The comments regarding missing clustered testing were largely out of date.
> Non-clustering testing for clustered http session code
> ------------------------------------------------------
>
> Key: JBAS-1483
> URL: http://jira.jboss.com/jira/browse/JBAS-1483
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Clustering
> Reporter: Ben Wang
> Assigned To: Brian Stansberry
> Fix For: JBossAS-5.0.1.CR1
>
> Original Estimate: 4 weeks
> Remaining Estimate: 4 weeks
>
> We need to have more black box testing for http requests without replication. Every feature in single node should also be supported by the clustered session manager and session classes. But currently, our testsuite largely only covers the clustered aspects.
> So here is two main steps:
> 1. Create an automated black box testing suite for http session request in a single node. We can use some tool to do this. Question is we need to define the tests.
> 2. Currently, Tomcat has a whole suite of unit testing on http session. We should look into that to see if we can re-use some of it in our own Tomcat module.
--
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
18 years, 6 months
[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
18 years, 6 months
[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
18 years, 7 months
[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
18 years, 7 months
[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
18 years, 7 months