[JBoss JIRA] Created: (JBWEB-167) Entropy value causing jsp display issues
by Mike Millson (JIRA)
Entropy value causing jsp display issues
----------------------------------------
Key: JBWEB-167
URL: https://jira.jboss.org/jira/browse/JBWEB-167
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core
Affects Versions: JBossWeb-2.1.7.GA
Reporter: Mike Millson
Assignee: Jean-Frederic Clere
The entropy value is causing some JBoss jmx-console pages to not render when the native connector is used.
For example, this link under jboss.web renders fine with the Java connector:
host=localhost,path=/jmx-console,type=Manager
I get the page back in the browser listing the MBean properties and functions.
But if I swap out the Java connector and use the native APR connector, I get no response.
Add the following if statement to inspectMBean.jsp to not print out the entropy value, and the page will display:
if(!attrName.equals("entropy")){
out.print("<input type='text' size='80' name='"+attrName+"' value='"+translateMetaCharacters(attrValue)+"' "+readonly+"/>");
}
--
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
16 years, 2 months
[JBoss JIRA] Created: (JGRP-1203) TCPGOSSIP: discovery fails when physical address is not yet known by coordinator
by Bela Ban (JIRA)
TCPGOSSIP: discovery fails when physical address is not yet known by coordinator
--------------------------------------------------------------------------------
Key: JGRP-1203
URL: https://jira.jboss.org/jira/browse/JGRP-1203
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.10
In TCPGOSSIP, the GossipRouter stores logical address (UUID), logical name (e.g. "A") and physical address (e.g. 192.168.1.5:7800) of each member. When a member P runs the discovery in TCPGOSSIP, it fetches all of this information, so it can send messages to all members in its cluster.
However, when member Q, who hasn't yet run a discovery (e.g. as part of MERGE2), needs to send a message back to P, since P's physical address won't be known yet, this will fail.
A concrete uses case is this:
- A has joined the cluster, became the coordinator as only member and registered with the GossipRouter
- B runs the discovery protocol, fetches information about A from GossipRouter in a first phase
- In a second phase, B sends a GET_MBRS_REQ to A, this works as B knows A's physical address
- A receives B's request and wants to send a GET_MBRS_RSP back to B
- However, as A didn't include its own physical address, A won't be able to send a message back to B ! Therefore B doesn't join the cluster, and will only later be merged with A !
- Only after the periodic merge kicks in, which runs a discovery on A, will A get B's physical address and will be able to talk to B !
==> SOLUTION: simple, B sends it metadata (physical address, logical name) *with* the GET_MBRS_REQ to A, so A will have B's physical address to send a message back to B. This is actually done in the other discovery protocols as well, e.g. TCPPING or PING...
--
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
16 years, 2 months