[Installation, Configuration & Deployment] - Re: How do I change the log4j levels dynamically?
by bbarlow
I have slightly more strict requirements, and was hoping for some help.
In our legacy J2SE environment, our application's JVM served up a very basic webpage that allowed us to dynamically alter the log4j Logger levels at runtime, without editing any log4j configuration files. The webpage was simply a form that listed all of the Loggers in the JVM in a hierarchical tree view (very much like how Chainsaw displays them), with comboboxes containing the available Levels for each Logger. The user could then choose new Levels for any or all loggers and submit the form. The server parsed the form arguments and made Logger.setLoggerLevel() calls appropriately.
This type functionality is extremely useful to my team, as we often have less technically skilled team members sitting at the system, trying to debug problems while consulting with the engineering team over the phone. It's much easier to ask someone to work with the tree view than to work with either the JBoss web console, the Sun JConsole, or via editing the log4j.xml file.
Is there some industry standard or open source tool that does what we're looking for, or is editing the log4j.xml file (or using the web console) really the standard, preferred approach to dynamically altering Logger levels? If not, what do you think the best approach for adding this functionality to the JBoss environment would be?
Thanks
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036158#4036158
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036158
19 years
[JBossCache] - HTTP Session Replication - immediate eviction
by lava_surfer
I am prototyping HTTP session replication for fail over in a 2 node cluster. JBoss AS version 4.0.3SP1, JBoss Cache version 1.4.0.SP1, JGroups default as per AS, JDK 1.5.0_08.
I have a simple two node cluster and a simple web application that writes a java.util.Date to the session each time the user clicks a submit button. The cluster appears to be working properly. Both nodes are present as verified via jmx-console in looking at the jboss service=My-Test-Partition-Tomcat and jboss.cache service=TomcatClusteringCache.
I have a jmx-console open on each node and observe the contents of the cache via the TomcatClusteringCache MBean printDetails() method.
I have enabled jboss cache DEBUG in log4j.xml.
Here's what happens in my test case:
1) Hit submit
2) Both nodes 1 and 2 store the updated session data as seen via jmx.
3) A second or two later, node 2 evicts the session data.
4) Node 1 retains the session data as per the configured eviction policy.
Perhaps I don't understand how the cache is supposed to work, but I am under the impression that each node would receive a copy of the session data as per the clustering configuration.
Thanks in advance for your help.
My tc5-cluster-service.xml is shown below.
|
| <?xml version="1.0" encoding="UTF-8"?>
|
| <!-- ===================================================================== -->
| <!-- -->
| <!-- Customized TreeCache Service Configuration for Tomcat 5 Clustering -->
| <!-- -->
| <!-- ===================================================================== -->
|
| <server>
|
| <!-- ==================================================================== -->
| <!-- Defines TreeCache configuration -->
| <!-- ==================================================================== -->
|
| <mbean code="org.jboss.cache.TreeCache"
| name="jboss.cache:service=TomcatClusteringCache">
|
| <depends>jboss:service=Naming</depends>
| <depends>jboss:service=TransactionManager</depends>
|
| <!-- Configure the TransactionManager -->
| <attribute name="TransactionManagerLookupClass">org.jboss.cache.JBossTransactionManagerLookup</attribute>
|
| <!--
| Node locking scheme:
| OPTIMISTIC
| PESSIMISTIC (default)
| -->
| <attribute name="NodeLockingScheme">OPTIMISTIC</attribute>
|
| <!--
| Isolation level : SERIALIZABLE
| REPEATABLE_READ (default)
| READ_COMMITTED
| READ_UNCOMMITTED
| NONE
| -->
| <attribute name="IsolationLevel">REPEATABLE_READ</attribute>
|
| <!--
| Valid modes are LOCAL, REPL_ASYNC and REPL_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">${jboss.partition.name:DefaultPartition}-Tomcat</attribute>
|
|
| <!-- JGroups protocol stack properties. Can also be a URL,
| e.g. file:/home/bela/default.xml
| <attribute name="ClusterProperties"></attribute>
| -->
|
| <attribute name="ClusterConfig">
| <!--
| The default UDP stack:
| - If you have a multihomed machine, set the UDP protocol's bind_addr attribute to the
| appropriate NIC IP address, e.g bind_addr="192.168.0.2".
| - On Windows machines, because of the media sense feature being broken with multicast
| (even after disabling media sense) set the UDP protocol's loopback attribute to true
| -->
| <config>
| <UDP mcast_addr="${jboss.partition.udpGroup: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"
| up_thread="false" down_thread="false"/>
| <MERGE2 min_interval="10000" max_interval="20000"/>
| <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"/>
| <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>
|
| <!-- Max number of milliseconds to wait for a lock acquisition -->
| <attribute name="LockAcquisitionTimeout">15000</attribute>
|
|
| <attribute name="EvictionPolicyClass">org.jboss.cache.eviction.LRUPolicy</attribute>
|
| <attribute name="EvictionPolicyConfig">
| <config>
| <attribute name="wakeUpIntervalSeconds">30</attribute>
| <region name="/_default_">
| <attribute name="maxNodes">10000</attribute>
| <attribute name="timeToLiveSeconds">1800</attribute>
| <attribute name="maxAgeSeconds">1800</attribute>
| </region>
| </config>
| </attribute>
|
| </mbean>
| </server>
|
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036153#4036153
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036153
19 years
[Clustering/JBoss] - Re: Configuration for redundant ethernets
by alpheratz-jb
Well, I have found a wrinkle...
If I run $JBOSS_HOME/probe.sh, I don't get a listing of the cluster members. The application doesn't show any errors, it just behaves/exits normally, just as it would if there were no cluster members.
Previously probe.sh gave me a listing of all the members in the cluster.
If I check a server log file, I see:
| 2007-04-10 11:07:02,262 WARN [org.jgroups.protocols.UDP] packet from
| 147.209.225.205:37242 has different version (25705) from ours (241).
| This may cause problems
| 2007-04-10 11:07:02,263 ERROR [org.jgroups.protocols.UDP] failed unmarshalling message java.io.EOFException
| at java.io.DataInputStream.readInt(DataInputStream.java:358)
| at org.jgroups.protocols.TP.bufferToList(TP.java:1020)
| at org.jgroups.protocols.TP.handleIncomingPacket(TP.java:827)
| at org.jgroups.protocols.TP.access$400(TP.java:45)
| at
| org.jgroups.protocols.TP$IncomingPacketHandler.run(TP.java:1296)
| at java.lang.Thread.run(Thread.java:595)
| 2007-04-10 11:10:58,178 WARN [org.jgroups.protocols.UDP] packet from
| 147.209.225.205:37262 has different version (25705) from ours (241).
| This may cause problems
|
I am going to try setting the compatibility flag -Djgroups.marshalling.compatible=true on the command line in probe.sh.
My guess is that this is what happens within JBoss 4.0.5GA which "built the fix into GA."?
I did have to hack probe.sh a little: to ensure that it picked up the version of jgroups.jar from one of the cluster member's server/lib directories, rather than using the one in default/all (forget which it was now...typing at home).
Will report back.
Cheers,
Alph
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036152#4036152
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4036152
19 years