January 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-5157) Twiddle to bad host/port returns data!

by Peter Hufnagel (JIRA)

Twiddle to bad host/port returns data! -------------------------------------- Key: JBAS-5157 URL: http://jira.jboss.com/jira/browse/JBAS-5157 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMX Affects Versions: JBossAS-4.2.1.GA, JBossAS-4.0.4RC1 Environment: 4.0.3SP1, 4.2.1.GA, RedHat AS3.0 x86 (32-bit) Reporter: Peter Hufnagel Assigned To: Dimitris Andreadis Priority: Minor It appears that twiddle fails to return an error, seems to connect to a random instance (multiple instances on multiple IP's) and return the data for that instance. [phufnag@cipcrpdwas01 ext]$ telnet 3.122.100.14 1099 Trying 3.122.100.14... telnet: connect to address 3.122.100.14: No route to host telnet: Unable to connect to remote host: No route to host IP is actually unpingable on the network entirely, not plumbed on this box at all... [phufnag@cipcrpdwas01 ext]$ /data/apps/jdk1.5.0_10/bin/java -Djava.endorsed.dirs=/data/apps/jboss-4.0.3SP1/lib/endorsed -Dprogram.name=twiddle.sh -classpath /data/apps/jboss-4.0.3SP1/bin/twiddle.jar:/data/apps/jboss-4.0.3SP1/client/jbossall-client.jar:/data/apps/jboss-4.0.3SP1/client/getopt.jar:/data/apps/jboss-4.0.3SP1/client/log4j.jar:/data/apps/jboss-4.0.3SP1/lib/jboss-jmx.jar:/data/apps/jboss-4.0.3SP1/lib/dom4j.jar org.jboss.console.twiddle.Twiddle -s 3.122.100.14:1099 serverinfo -l jboss.management.local:ServiceModule=jboss-service.xml,name=jboss%3aservice%3dinvoker%2ctype%3djrmp,J2EEServer=Local,J2EEApplication=null,j2eeType=MBean jboss.jca:service=CachedConnectionManager jboss.management.local:ServiceModule=jbossjca-service.xml,name=jboss.jca%3aservice%3dWorkManagerThreadPool,J2EEServer=Local,J2EEApplication=null,j2eeType=MBean jboss.management.local:ServiceModule=jmx-invoker-service.xml,name=jboss.jmx%3atype%3dadaptor%2cname%3dInvoker%2cprotocol%3djrmp%2cservice%3dproxyFactory,J2EEServer=Local,J2EEApplication=null,j2eeType=MBean ... (truncated the output, you get the idea returns a full Mbean list for an instance on the box listening on an entirely different IP). If I run the exact same command several times in a row, it will connect to different instances each time - the ".14" IP isn't plumbed on the box at all, it however returns data from the instances listening on .23, .24, .153, etc (we have about 10 instances running). -- 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, 5 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAS-3637) Way to set JNDI properties for twiddle

by Owen Taylor (JIRA)

Way to set JNDI properties for twiddle -------------------------------------- Key: JBAS-3637 URL: http://jira.jboss.com/jira/browse/JBAS-3637 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Owen Taylor Priority: Minor It is frequently useful to be able to set JDNI properties when running twiddle - for example, you might want to set jnp.disableDiscovery when checking the status of a particular server that might not be running. Right now, this is difficult to do. You can export a JBOSS_CLASSPATH which contains a jndi.properties file before running twiddle.sh, but then you have to include all the standard jars in it, which is quite annoying. A pssible fixes would be one of: A) A way to prepend elements to JBOSS_CLASSPATH without disabling the default construction (also useful for getting a log4j.properties that doesn't drop twiddle.log in the cwd, perhaps) B) A command line option for specifying a particular properties file to load and pass to 'new InitialContext()' (slightly more convenient than A) C) A command line option to define particular properties: twiddle.sh -jnpProperty=jnp.disableDiscovery=true (Or some better syntax) The twiddle code actually does: Properties props = new Properties(System.getProperties()); props.put(Context.PROVIDER_URL, serverURL); ctx = new InitialContext(props); In the case where a server URL is set, so there may have been intention that twiddle.sh -Djnp.disableDiscovery=true would work, but AFAIK property inheritance doesn't work in that place - only the properties directly in props take effect, and system properties won't be looked at in the other code path either. -- 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, 5 months

4
4
0 / 0

[JBoss JIRA] Created: (JBAS-5108) Create a HashMap PropertyEditor For Use By Applications Such As Twiddle

by Jimmy Wilson (JIRA)

Create a HashMap PropertyEditor For Use By Applications Such As Twiddle ----------------------------------------------------------------------- Key: JBAS-5108 URL: http://jira.jboss.com/jira/browse/JBAS-5108 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Management services Affects Versions: JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA Reporter: Jimmy Wilson Assigned To: Dimitris Andreadis Priority: Minor Twiddle, for example, needs a HashMap to String property editor (it does not need the reverse) so that results of MBean invocations that return HashMaps can be properly displayed. -- 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, 5 months

2
4
0 / 0

[JBoss JIRA] Created: (JGRP-606) Use same properties for start_port/bind_port and end_port/port_range

by Bela Ban (JIRA)

Use same properties for start_port/bind_port and end_port/port_range -------------------------------------------------------------------- Key: JGRP-606 URL: http://jira.jboss.com/jira/browse/JGRP-606 Project: JGroups Issue Type: Task Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.7 In UDP, we use bind_port and port_range to define a range of valid ports. In TCP, we use start_port and end_port We should use - bind_port (rather than start_port) to define the port to bind to - end_port to define the range -- 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, 5 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-4962) Upgrade jboss remoting to v2.2.2.SP2 (from v2.2.2.SP1)

by Dimitris Andreadis (JIRA)

Upgrade jboss remoting to v2.2.2.SP2 (from v2.2.2.SP1) ------------------------------------------------------ Key: JBAS-4962 URL: http://jira.jboss.com/jira/browse/JBAS-4962 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Remoting Affects Versions: JBossAS-4.2.2.GA Reporter: Dimitris Andreadis Assigned To: Dimitris Andreadis Fix For: JBossAS-4.2.3.GA Use the latest compatible version of JBoss Remoting -- 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, 5 months

1
5
0 / 0

[JBoss JIRA] Created: (JGRP-658) STATE_TRANSFER Nullpointer Exception

by Benoit PINGAT (JIRA)

STATE_TRANSFER Nullpointer Exception ------------------------------------ Key: JGRP-658 URL: http://jira.jboss.com/jira/browse/JGRP-658 Project: JGroups Issue Type: Bug Affects Versions: 2.4.1 SP3 Environment: JDK 1.5 Reporter: Benoit PINGAT Assigned To: Bela Ban Hello, we faced the following problem after running this sequence: Our cluster was running well for 24h on a single machine then one node was detected as dead (without any obvious reason). Anyway, the node was shutdown as it discovered it was ejected from the cluster view. Then, the coordinator get this error : 05:58:20,613 WARN [NAKACK][UpHandler (NAKACK)] 130.22.107.60:33612] discarded message from non-member 130.22.107.60:33618, my view is [130.22.107.60:33612|5] [130.22.107.60:33612, 130.22.107.60:33616, 130.22.107.60:33622, 130.22.107.60:33624] 05:58:21,612 WARN [NAKACK][UpHandler (NAKACK)] 130.22.107.60:33612] discarded message from non-member 130.22.107.60:33618, my view is [130.22.107.60:33612|5] [130.22.107.60:33612, 130.22.107.60:33616, 130.22.107.60:33622, 130.22.107.60:33624] 05:58:22,618 WARN [NAKACK][UpHandler (NAKACK)] 130.22.107.60:33612] discarded message from non-member 130.22.107.60:33618, my view is [130.22.107.60:33612|5] [130.22.107.60:33612, 130.22.107.60:33616, 130.22.107.60:33622, 130.22.107.60:33624] 05:58:23,628 WARN [NAKACK][UpHandler (NAKACK)] 130.22.107.60:33612] discarded message from non-member 130.22.107.60:33618, my view is [130.22.107.60:33612|5] [130.22.107.60:33612, 130.22.107.60:33616, 130.22.107.60:33622, 130.22.107.60:33624] 05:58:25,369 ERROR [DownHandler][DownHandler (STATE_TRANSFER)] DownHandler (STATE_TRANSFER) caught exception java.lang.NullPointerException at org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:252) at org.jgroups.stack.DownHandler.run(Protocol.java:121) (the member with the JGadress 130.22.107.60:33618 is the one that failed) May we know what causes this error and how to correct it ? Regards -- 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

4
6
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-200) AOP/MC Proxies do not include original annotations

by Kabir Khan (JIRA)

AOP/MC Proxies do not include original annotations -------------------------------------------------- Key: JBMICROCONT-200 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-200 Project: JBoss MicroContainer Issue Type: Bug Components: AOP Affects Versions: JBossMC_2_0_0 Beta3 Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: JBossMC-2.0.0.CR1 -- 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

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-876) Get Remoting testsuite to run in hudson

by Ron Sigal (JIRA)

Get Remoting testsuite to run in hudson --------------------------------------- Key: JBREM-876 URL: http://jira.jboss.com/jira/browse/JBREM-876 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) The jrunit based Remoting tests are failing in hudson. The problem might be that jrunit depends on multicasting in jgroups. Aleksandar Kostadinov has said: 1. Let me know if it is related to multicast listener on lo and a multicast sender. There is a change in behavior after RHEL 4.4 in that regard and I suspect that is the reason tests to pass on the old build hosts and not on the new hudson ones. 2. How can we make it not bind to localhost? I don't think it will be possible to have these passing without that. Will -Dbind_addr=something and -Dlocal_addr=something change that or this has to be done in some property files as well? -- 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

1
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-989) Create performance test suite to test failover

by Manik Surtani (JIRA)

Create performance test suite to test failover ---------------------------------------------- Key: JBCACHE-989 URL: http://jira.jboss.com/jira/browse/JBCACHE-989 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.0.0.GA Should be ideally integrated into cruise control builds, and should test a variety of configurations including sync and async replication, BR, etc. -- 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

1
5
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-105) Refactor the VFS.isArchive and structural deployers

by Scott M Stark (JIRA)

Refactor the VFS.isArchive and structural deployers --------------------------------------------------- Key: JBMICROCONT-105 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-105 Project: JBoss MicroContainer Issue Type: Task Reporter: Scott M Stark We have been arguing about the ambiguity/utility of the vfs isArchive with regard to determing deployment strucutre. Proper separation of behavior would remove isArchive from the vfs and update the structural deployment spi to allow reuse of the structural parse without having to pull in jboss5/MainDeployer + all deployers. A related structure deployer discussion: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=92529 VFS visiting: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=92141 VFS isArchive removal: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=92139 -- 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

2
5
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2008