[jboss-jira] [JBoss JIRA] Updated: (JGRP-1115) TCPPING cookie read error on load
Sanjay Prasad (JIRA)
jira-events at lists.jboss.org
Thu Dec 17 04:57:30 EST 2009
[ https://jira.jboss.org/jira/browse/JGRP-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sanjay Prasad updated JGRP-1115:
--------------------------------
Description:
BasicConnectionTable.java in JGroups-2.4.1-sp4.src/src/org/jgroups/blocks does not use readFully to read the cookie and so during high load, runs into cookie related error. Changing the line to readFully fixes the issue.
if(in != null) {
initCookie(input_cookie);
// read the cookie first
in.read(input_cookie, 0, input_cookie.length);
if(!matchCookie(input_cookie))
throw new SocketException("ConnectionTable.Connection.readPeerAddress(): cookie sent by " +
client_peer_addr + " does not match own cookie; terminating connection");
// then read the version
version=in.readShort();
doSend when it fails, removes the connection in the exception block and so the second try in _send always fails with the error "2nd attempt to send data failed too" as the connection is already closed.
void doSend(byte[] data, int offset, int length) throws Exception {
try {
// we're using 'double-writes', sending the buffer to the destination in 2 pieces. this would
// ensure that, if the peer closed the connection while we were idle, we would get an exception.
// this won't happen if we use a single write (see Stevens, ch. 5.13).
if(out != null) {
out.writeInt(length); // write the length of the data buffer first
Util.doubleWrite(data, offset, length, out);
out.flush(); // may not be very efficient (but safe)
}
}
catch(Exception ex) {
remove(peer_addr);
throw ex;
}
}
private void _send(byte[] data, int offset, int length) {
synchronized(send_mutex) {
try {
doSend(data, offset, length);
updateLastAccessed();
}
catch(IOException io_ex) {
if(log.isWarnEnabled())
log.warn("peer closed connection, trying to re-send msg");
try {
doSend(data, offset, length);
updateLastAccessed();
}
catch(IOException io_ex2) {
if(log.isErrorEnabled()) log.error("2nd attempt to send data failed too");
}
was:
BasicConnectionTable.java in JGroups-2.4.1-sp4.src/src/org/jgroups/blocks does not use readFully to read the cookie and so during high load, runs into cookie related error. Changing the line to readFully fixes the issue.
499
500 // read the cookie first
501 in.read(input_cookie, 0, input_cookie.length);
502 if(!matchCookie(input_cookie))
503 throw new SocketException("ConnectionTable.Connection .readPeerAddress(): cookie sent by " +
504 client_peer_addr + " does n ot match own cookie; terminating connection");
505 // then read the version
506 version=in.readShort();
507
doSend when it fails, removes the connection in the exception block and so the second try in _send always fails with the error "2nd attempt to send data failed too" as the connection is already closed.
void doSend(byte[] data, int offset, int length) throws Exception {
try {
// we're using 'double-writes', sending the buffer to the destination in 2 pieces. this would
// ensure that, if the peer closed the connection while we were idle, we would get an exception.
// this won't happen if we use a single write (see Stevens, ch. 5.13).
if(out != null) {
out.writeInt(length); // write the length of the data buffer first
Util.doubleWrite(data, offset, length, out);
out.flush(); // may not be very efficient (but safe)
}
}
catch(Exception ex) {
remove(peer_addr);
throw ex;
}
}
private void _send(byte[] data, int offset, int length) {
synchronized(send_mutex) {
try {
doSend(data, offset, length);
updateLastAccessed();
}
catch(IOException io_ex) {
if(log.isWarnEnabled())
log.warn("peer closed connection, trying to re-send msg");
try {
doSend(data, offset, length);
updateLastAccessed();
}
catch(IOException io_ex2) {
if(log.isErrorEnabled()) log.error("2nd attempt to send data failed too");
}
> TCPPING cookie read error on load
> ---------------------------------
>
> Key: JGRP-1115
> URL: https://jira.jboss.org/jira/browse/JGRP-1115
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.4.1 SP4
> Environment: red hat linux 2.6.9-78.0.8.EL 64 bit, java 1.5, jboss 4.2.2
> Reporter: Sanjay Prasad
> Assignee: Bela Ban
>
> BasicConnectionTable.java in JGroups-2.4.1-sp4.src/src/org/jgroups/blocks does not use readFully to read the cookie and so during high load, runs into cookie related error. Changing the line to readFully fixes the issue.
> if(in != null) {
> initCookie(input_cookie);
> // read the cookie first
> in.read(input_cookie, 0, input_cookie.length);
> if(!matchCookie(input_cookie))
> throw new SocketException("ConnectionTable.Connection.readPeerAddress(): cookie sent by " +
> client_peer_addr + " does not match own cookie; terminating connection");
> // then read the version
> version=in.readShort();
> doSend when it fails, removes the connection in the exception block and so the second try in _send always fails with the error "2nd attempt to send data failed too" as the connection is already closed.
> void doSend(byte[] data, int offset, int length) throws Exception {
> try {
> // we're using 'double-writes', sending the buffer to the destination in 2 pieces. this would
> // ensure that, if the peer closed the connection while we were idle, we would get an exception.
> // this won't happen if we use a single write (see Stevens, ch. 5.13).
> if(out != null) {
> out.writeInt(length); // write the length of the data buffer first
> Util.doubleWrite(data, offset, length, out);
> out.flush(); // may not be very efficient (but safe)
> }
> }
> catch(Exception ex) {
> remove(peer_addr);
> throw ex;
> }
> }
> private void _send(byte[] data, int offset, int length) {
> synchronized(send_mutex) {
> try {
> doSend(data, offset, length);
> updateLastAccessed();
> }
> catch(IOException io_ex) {
> if(log.isWarnEnabled())
> log.warn("peer closed connection, trying to re-send msg");
> try {
> doSend(data, offset, length);
> updateLastAccessed();
> }
> catch(IOException io_ex2) {
> if(log.isErrorEnabled()) log.error("2nd attempt to send data failed too");
> }
--
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
More information about the jboss-jira
mailing list