[JBoss JIRA] Updated: (JBAS-1436) Improved management
by Ian Springer (JIRA)
[ https://jira.jboss.org/jira/browse/JBAS-1436?page=com.atlassian.jira.plug... ]
Ian Springer updated JBAS-1436:
-------------------------------
Affects Version/s: JBossAS-5.1.0.GA
Complexity: Medium
Priority: Major (was: Minor)
> Improved management
> -------------------
>
> Key: JBAS-1436
> URL: https://jira.jboss.org/jira/browse/JBAS-1436
> Project: JBoss Application Server
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: JCA service
> Affects Versions: JBossAS-5.1.0.GA
> Reporter: Adrian Brock
> Assignee: Vicky Kak
> Fix For: JBossAS-6.0.0.Alpha1
>
>
> 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: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 1 month
[JBoss JIRA] Created: (JGRP-986) FLUSH: relax event sequencing for a joining member
by Vladimir Blagojevic (JIRA)
FLUSH: relax event sequencing for a joining member
--------------------------------------------------
Key: JGRP-986
URL: https://jira.jboss.org/jira/browse/JGRP-986
Project: JGroups
Issue Type: Bug
Affects Versions: 2.6.10, 2.8
Reporter: Vladimir Blagojevic
Assignee: Vladimir Blagojevic
Fix For: 2.6.11, 2.8
There is a possibility that a message could get dropped for a joining member C as it joins a cluster (and it should not get dropped). Flush has a latch (allowMessagesToPassUp) that is turned on once a joining member C receives a first stop flush - received right after a first view, sent from coordinator, say member A. If a message M from another member B happens to go up the stack before first stop flush reaches C - member C drops message M. This latch was introduced to always enforce a strict order between view, unblock and message M.
If we did not have this switch then we could have reverse order of unblock and a message M, that is messages could go up the stack before unblock. Note that this does not violate virtual synchrony in any way - messages are still received after the first view. However, we need to document unblock callback to clearly make a note of this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 1 month
[JBoss JIRA] Created: (JGRP-987) Make many classes immutable
by Bela Ban (JIRA)
Make many classes immutable
---------------------------
Key: JGRP-987
URL: https://jira.jboss.org/jira/browse/JGRP-987
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.x
Currently, a lot of classes could be immutable if it wasn't for the readFrom() method to initialize itself from an input stream.
However, if we had a factory, which reads and constructs immutable instances of classes, then we could turn a lot of classes into immutable classes, for example all headers should be immutable.
The code for marshalling and unmarshalling could be generated, e.g. based on an XML description of the data layout of a class.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 1 month
[JBoss JIRA] Created: (JGRP-912) Failed to parse the jgroups.xml file
by sridhar reddy (JIRA)
Failed to parse the jgroups.xml file
------------------------------------
Key: JGRP-912
URL: https://jira.jboss.org/jira/browse/JGRP-912
Project: JGroups
Issue Type: Bug
Affects Versions: 2.6.8
Environment: jdk 6, jboss cache 3.0.2 GA, jgroup 2.6.8, wind0ws XP
Reporter: sridhar reddy
Assignee: Bela Ban
Priority: Blocker
I have the following jboss cache xml as below
[code]
<?xml version="1.0" encoding="UTF-8"?>
<jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:jboss:jbosscache-core:config:3.0">
<locking isolationLevel="READ_COMMITTED"
lockParentForChildInsertRemove="false" lockAcquisitionTimeout="20000"
nodeLockingScheme="mvcc" writeSkewCheck="false"
concurrencyLevel="500" />
<transaction
transactionManagerLookupClass="org.jboss.cache.transaction.GenericTransactionManagerLookup"
syncRollbackPhase="false" syncCommitPhase="false" />
<eviction wakeUpInterval="500">
<default algorithmClass="org.jboss.cache.eviction.LRUAlgorithm"
eventQueueSize="200000">
<property name="maxNodes" value="5000" />
<property name="timeToLive" value="1000" />
</default>
<region name="/org/jboss/data1">
<property name="timeToLive" value="2000" />
</region>
<region name="/org/jboss/data2"
algorithmClass="org.jboss.cache.eviction.FIFOAlgorithm"
eventQueueSize="100000">
<property name="maxNodes" value="3000" />
<property name="minTimeToLive" value="4000" />
</region>
</eviction>
<clustering mode="replication" >
<jgroupsConfig configFile="C:/workspace/GridJBCache3/src/config/jgroups.xml" />
</clustering>
<loaders passivation="false" shared="false">
<preload>
<node fqn="/" />
</preload>
<loader class="org.jboss.cache.loader.JDBCCacheLoader"
async="true" fetchPersistentState="true" ignoreModifications="true"
purgeOnStartup="true">
<properties>
cache.jdbc.table.name=jbosscache
cache.jdbc.table.create=true
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=bytea
cache.jdbc.parent.column=parent
cache.jdbc.driver=org.postgresql.Driver
cache.jdbc.url=jdbc:postgresql://localhost:5432/facts7
cache.jdbc.user=f7tms
cache.jdbc.password=f7tms
</properties>
</loader>
</loaders>
</jbosscache>
[/code]
and jgroups.xml file as below
[code]
<config>
<UDP mcast_addr="${jgroups.udp.mcast_addr:228.10.10.10}"
mcast_port="${jgroups.udp.mcast_port:45588}" tos="8"
ucast_recv_buf_size="20000000" ucast_send_buf_size="640000"
mcast_recv_buf_size="25000000" mcast_send_buf_size="640000"
loopback="false" discard_incompatible_packets="true"
max_bundle_size="64000" max_bundle_timeout="30"
use_incoming_packet_handler="true" ip_ttl="${jgroups.udp.ip_ttl:2}"
enable_bundling="true" enable_diagnostics="true"
thread_naming_pattern="cl" use_concurrent_stack="true"
thread_pool.enabled="true" thread_pool.min_threads="2"
thread_pool.max_threads="8" thread_pool.keep_alive_time="5000"
thread_pool.queue_enabled="true" thread_pool.queue_max_size="1000"
thread_pool.rejection_policy="discard"
oob_thread_pool.enabled="true" oob_thread_pool.min_threads="1"
oob_thread_pool.max_threads="8"
oob_thread_pool.keep_alive_time="5000"
oob_thread_pool.queue_enabled="false"
oob_thread_pool.queue_max_size="100"
oob_thread_pool.rejection_policy="Run" />
<PING timeout="2000" num_initial_members="3" />
<MERGE2 max_interval="30000" min_interval="10000" />
<FD_SOCK />
<FD timeout="10000" max_tries="5" shun="true" />
<VERIFY_SUSPECT timeout="1500" />
<BARRIER />
<pbcast.NAKACK use_stats_for_retransmission="false"
exponential_backoff="150" use_mcast_xmit="true" gc_lag="0"
retransmit_timeout="50,300,600,1200" discard_delivered_msgs="true" />
<UNICAST timeout="300,600,1200" />
<pbcast.STABLE stability_delay="1000"
desired_avg_gossip="50000" max_bytes="1000000" />
<VIEW_SYNC avg_send_interval="60000" />
<pbcast.GMS print_local_addr="true" join_timeout="3000"
shun="false" view_bundling="true" />
<FC max_credits="500000" min_threshold="0.20" />
<FRAG2 frag_size="60000" />
-
<!-- pbcast.STREAMING_STATE_TRANSFER /
-->
<pbcast.STATE_TRANSFER />
-
<!-- pbcast.FLUSH /
-->
</config>
[/code]
My code start the cache as
[code]
package org.gridgain.examples.jbosscache;
import java.io.File;
import org.jboss.cache.Cache;
import org.jboss.cache.CacheFactory;
import org.jboss.cache.DefaultCacheFactory;
import org.jboss.cache.Fqn;
import org.jboss.cache.Node;
import org.jboss.cache.config.Configuration;
import org.jboss.cache.config.parsing.XmlConfigurationParser;
import org.jgroups.JChannelFactory;
public final class GridJbossCacheManager {
/** Cache configuration path relative to GridGain installation. */
public static final String CACHE_CFG_PATH = "C:/workspace/GridJBCache3/src/config/jboss-cache.xml";
/** JGroups configuration path relative to GridGain installation. */
public static final String JGROUPS_CFG_PATH = "C:/workspace/GridJBCache3/src/config/jgroups.xml";
/** JBoss Cache instance. */
private Cache<Long, String> cache = null;
/** Cache node for caching example data. */
private Node<Long, String> cacheRoot = null;
/** Singleton instance. */
private static GridJbossCacheManager instance = new GridJbossCacheManager();
/**
* Gets singleton.
*
* @return Singleton.
*/
public static GridJbossCacheManager getInstance() {
return instance;
}
/**
* Ensure singleton.
*/
private GridJbossCacheManager() {
// No-op.
}
public void start() throws GridException {
File cacheCfg = new File(CACHE_CFG_PATH);
if (cacheCfg == null) {
throw new GridException("Failed to find cache configuration file: " + CACHE_CFG_PATH);
}
File jgroupsCfg = new File(JGROUPS_CFG_PATH);
if (jgroupsCfg == null) {
throw new GridException("Failed to find jgroups configuration: " + JGROUPS_CFG_PATH);
}
// Make sure JBoss Cache and GridGain are on the same "wave length".
JChannelFactory factory = new JChannelFactory(); //null;
try {
//factory = new JChannelFactory(jgroupsCfg);
factory.setMultiplexerConfig(jgroupsCfg.getCanonicalPath());
}
catch (Exception e) {
throw new GridException("Failed to start Data Manager.", e);
}
try {
XmlConfigurationParser parser = new XmlConfigurationParser();
// Start JBoss Cache cache with shared JGroups configuration.
Configuration svrCfg = parser.parseFile(cacheCfg.getCanonicalPath());
svrCfg.getRuntimeConfig().setMuxChannelFactory(factory);
CacheFactory<Long, String> dataFactory = DefaultCacheFactory.getInstance();
// Instantiate and start JBoss Cache.
cache = dataFactory.createCache(svrCfg);
// Cache node for storing example data.
cacheRoot = cache.getRoot().addChild(Fqn.fromString("/"));
}
catch (Exception e) {
throw new GridException("Failed to start Data Manager.", e);
}
System.out.println("JBoss Cache data manager started.");
}
}
[/code]
When i ran this program i am getting the following error
[code]
Exception in thread "main"
Exception:
----------
>>> Type: java.lang.Exception
>>> Message: failed parsing C:\workspace\GridJBCache3\src\config\jgroups.xml
>>> Stack trace:
>>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:216)
>>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:205)
>>> at org.gridgain.examples.jbosscache.GridJbossCacheManager.start(GridJbossCacheManager.java:131)
>>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.loadNode(GridJbossCacheExampleNodeLoader.java:38)
>>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.main(GridJbossCacheExampleNodeLoader.java:58)
Caused By:
----------
>>> Type: java.io.IOException
>>> Message: invalid XML configuration: XML protocol stack configuration does not start with a '<config>' element; maybe the XML configuration needs to be converted to the new format ?
use 'java org.jgroups.conf.XmlConfigurator <old XML file> -new_format' to do so
>>> Stack trace:
>>> at org.jgroups.JChannelFactory.parse(JChannelFactory.java:476)
>>> at org.jgroups.JChannelFactory.parse(JChannelFactory.java:462)
>>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:213)
>>> at org.jgroups.JChannelFactory.setMultiplexerConfig(JChannelFactory.java:205)
>>> at org.gridgain.examples.jbosscache.GridJbossCacheManager.start(GridJbossCacheManager.java:131)
>>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.loadNode(GridJbossCacheExampleNodeLoader.java:38)
>>> at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.main(GridJbossCacheExampleNodeLoader.java:58)
[/code]
Now i have added the
[code]
<protocol_stacks>
<stack name="udp"
description="Default: IP multicast based stack, with flow control and message bundling">
[/code]
to jgroups.xml. When i ran the program, its giving the following error.
[code]
log4j:WARN No appenders could be found for logger (org.jboss.cache.util.FileLookup).
log4j:WARN Please initialize the log4j system properly.
Exception in thread "main" org.jboss.cache.CacheException: java.lang.reflect.InvocationTargetException
at org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:148)
at org.jboss.cache.factories.ComponentRegistry$PrioritizedMethod.invoke(ComponentRegistry.java:1005)
at org.jboss.cache.factories.ComponentRegistry.internalStart(ComponentRegistry.java:775)
at org.jboss.cache.factories.ComponentRegistry.start(ComponentRegistry.java:629)
at org.jboss.cache.invocation.CacheInvocationDelegate.start(CacheInvocationDelegate.java:344)
at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:121)
at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:105)
at org.gridgain.examples.jbosscache.GridJbossCacheManager.start(GridJbossCacheManager.java:148)
at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.loadNode(GridJbossCacheExampleNodeLoader.java:38)
at org.gridgain.examples.jbosscache.GridJbossCacheExampleNodeLoader.main(GridJbossCacheExampleNodeLoader.java:58)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:144)
... 9 more
Caused by: org.jboss.cache.CacheException: Failed to create multiplexed channel using stack null
at org.jboss.cache.RPCManagerImpl.getMultiplexerChannel(RPCManagerImpl.java:353)
at org.jboss.cache.RPCManagerImpl.initialiseChannelAndRpcDispatcher(RPCManagerImpl.java:267)
at org.jboss.cache.RPCManagerImpl.start(RPCManagerImpl.java:167)
... 14 more
Caused by: java.lang.IllegalArgumentException: stack name and service ID have to be non null
at org.jgroups.JChannelFactory.createMultiplexerChannel(JChannelFactory.java:336)
at org.jgroups.JChannelFactory.createMultiplexerChannel(JChannelFactory.java:328)
at org.jboss.cache.RPCManagerImpl.getMultiplexerChannel(RPCManagerImpl.java:349)
... 16 more
[/code]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 1 month
[JBoss JIRA] Created: (JGRP-964) shared_transport concurrency problem - starting several at the same time causes "timer cannot be retrieved from protocol stack"
by Edward Kuns (JIRA)
shared_transport concurrency problem - starting several at the same time causes "timer cannot be retrieved from protocol stack"
-------------------------------------------------------------------------------------------------------------------------------
Key: JGRP-964
URL: https://jira.jboss.org/jira/browse/JGRP-964
Project: JGroups
Issue Type: Bug
Affects Versions: 2.7
Environment: Win2000, JVM = JRockit 6
Reporter: Edward Kuns
Assignee: Bela Ban
Attachments: CoordinationBus.xml
I have an application that starts four jgroups NotificationBus's that all share the same UDP transport (with singleton_name="...") but are otherwise distinct. Recently, the application started to fail to start with the following stack signature:
2009-04-27 13:56:50,425 -0500 ERROR [JGroupsTest] - Exception running bus
org.jgroups.ChannelException: unable to setup the protocol stack: timer cannot be retrieved from protocol stack
at org.jgroups.JChannel.init(JChannel.java:1574)
at org.jgroups.JChannel.<init>(JChannel.java:257)
at org.jgroups.JChannel.<init>(JChannel.java:240)
at org.jgroups.blocks.NotificationBus.<init>(NotificationBus.java:69)
at JGroupsTest$1.run(JGroupsTest.java:25)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.Exception: timer cannot be retrieved from protocol stack
at org.jgroups.protocols.Discovery.init(Discovery.java:98)
at org.jgroups.protocols.PING.init(PING.java:84)
at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:641)
at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:468)
at org.jgroups.JChannel.init(JChannel.java:1570)
... 5 more
I created a test application that does nothing but start these four busses, and if I start them simultaneously, I can always reproduce the above error. I will attach the test application.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 1 month
