Recent changes to bugs

PiggyBack reply

J-B — Thu, 01 Jun 2006 19:34:32 -0000

It was shown that channel.getStartData() was deprecated.
However, it seems to me that beepcore-java do not have
other
method to get the PiggyBackReply from the server.
Why it was deprecated while there is not alternative?

SessionListener.greetingReceived is never called.

Warren Janssens — Sat, 18 Feb 2006 00:29:41 -0000

The root cause is that the method
SessionImpl.fireGreetingReceived() is never called.

removeSessionListener, get NullPointerExce

Pete Siemsen — Wed, 23 Nov 2005 23:25:14 -0000

If you

1. open a session
2. add a sessionlistener
3. remove the sessionListener
4. close the session

...you'll get a NullPointerException.

The problem is in SessionImpl.java, and affects both
sessions and channels, which use similar code to
maintain lists of listeners. For some reason, a
list is maintained and an array is maintained
containing the same information. The problem comes
from this odd implementation (why not use just a
List?).
In removeSessionListener, the object is removed from
the list, and then the list is converted to the array,
but a zero-length List doesn't get converted to an
empty array. From the docs for toArray():

If the list fits in the specified array with room
to spare (i.e., the array has more elements than
the list), the element in the array immediately
following the end of the collection is set to null.

The above is always true in removeSessionListener,
so the array gets one more element than the writer
intended. Later, when, say, fireSessionTerminated
is called, it tests for an array length of zero.
The array has one (null) element, the test fails,
the null is accessed, and a NullPointerException
happens.

I fixed this by changing the tests in the six fireXXX
methods to make them check for a list size of zero
instead of an array length of zero. It seems that
this code and the corresponding add/remove methods
would be better if Lists were used and the arrays
were dropped.

Updated patches

Dong Xin — Mon, 21 Mar 2005 20:34:40 -0000

We found a better way to fix the bugs in previous reports:
1116373
1054893
1023951

Reply.getNextReply locks up the thread

beep@tomoton — Tue, 15 Feb 2005 16:25:51 -0000

After experimenting with the Bing profile, in a test
scenario charting the post-failure behaviour of the the
most recent Java BeepCore implementation, a thread
could be locked in a wait state without any opportunity
for other threads to notify it to continue.

The thread cannot be notified because it's the only
thread left 'running' inside the VM.

The problem occurs when during the EchoProfile session,
one of the peer's cables become unplugged.

The blocking wait is invoked inside the reply object in
the method getNextReply.

As this is a connection-oriented protocol, the Reply
object should be kept informed about the life-cycle of
the associated channel. Currently, it would appear it
doesn't.

TuningProfile

Dong Xin — Fri, 04 Feb 2005 18:32:19 -0000

We were trying to implement saslsrp in beepcore. The
problem
we found in the current implementation are:

1. The SEQ message are always sent out before the message
is processed in non-tuning mode, since we want to
switch the
ordinary socket to an SRPsocket, the SEQ message introduces
difficulties to synchronize a point where both peers
can safely
switch the underlying socket.

2. If we use the tuning mode, both server and client
side will
communicate via raw socket layer. Since we have to follow
the SASLProfile to implement SASLSRP, this TLS like
approach
is not desirable.

We made two patch files for ChannelImpl and Channel to fix
the above problems. More specifically, we add more
state variables
which help us still use the beepcore framework while in
tuning.

channel.getStartData()

Dong Xin — Tue, 26 Oct 2004 22:06:38 -0000

issue with startChannel on a shared Session

ceek63 — Tue, 26 Oct 2004 01:49:25 -0000

I've 2 peers trying to start their own channel on the
each other's Profile on a shared
Session.
Peer A to Peer B communication is fine. When Peer B
tries to reuse the
received Session object to start the Channel using
session.startChannel(ProfileA),
I get this exception of Unsupported profile.

Here's the code on PeerA:
public class Client implements
Profile,StartChannelListener,org.beepcore.beep.core.Requ
estHandler
{
....register profileA
reg.addStartChannelListener(uri,
p.init(uri, profileConfig),
tuning);
...
//initiate session
session = TCPSessionCreator.initiate(host, port);
channel = session.startChanne(ProfileB);
Now send the message here.. Works fine

//Has other callbacks implemented similar to
EchoProfile

}

Code on PeerB:
public class Server implements
Profile,StartChannelListener,org.beepcore.beep.core.Requ
estHandler
{
....register profileB
reg.addStartChannelListener(uri,
p.init(uri, profileConfig),
tuning);
...

public void startChannel(Channel channel, String
encoding, String data)
throws StartChannelException
{
channel.setRequestHandler(this);
//STORE THE SESSION here.. is this a problem??
peerSession = channel.getSession();
}

//Has other callbacks implemented similar to
EchoProfile

}

On the PeerB side, in a different Java class I try to
use the peerSession object above to startChanel that's
when I get the exception:
org.beepcore.beep.core.SessionImpl$StartReplyListener
receiveERR
> SEVERE: Received an error in response to a start.
code=550
> diagnostic=all requested profiles are unsupported

This is how I call startChannel:
Channel channel;
try {

//session object being used here
is stored after this peer received the message from the
other Peer. Can I use this stored session to start a
Channel on the other peers' profile?? This where I get
the exception.
channel =
session.startChannel(ProfileA);
} catch (BEEPError e) {
}

I checked the profile info on both sides and are OK.

In summary, PeerA to PeerB communication is OK
PeerB also receives the Reply from PeerA. But PeerB
can't startChannel() on peerA.

PiggyBack

Dong Xin — Tue, 07 Sep 2004 20:08:30 -0000

I am not sure where it is my misusage or a bug in beepcore.

Here is what we traced when piggyback is used.
Client:
StartChannelRequest with a piggybacked data

Server:
1. ProcessStartChannelRequest
2. detect the piggybacked MSG and put in the recvMSGQueue
of a new channel (say channel 1)
3. Channel 1 is invoked to process the piggybacked MSG
4. In PiggybackMSG.sendRPY, the reply data is given to
channel 0
5. Channel 0 send the piggybacked reply to client,
remove msg from
the head of recvMSGQueue of channle 0, while leaviing a
msg at the head of recvMSGQueue of channel 1

Next time, when client send another request, there are
two msgs in
the recvMSGQueue in channel 1, the channel 1 will not
process any
message at all, because the condition to process
message is
to check whether the size of recvMSGQueue is 1.

InputDataStreamAdapter doesn't handle msgs w/o a MIME header

Wladimir Araujo — Mon, 19 Jan 2004 23:48:04 -0000

This class expects a message that explicitly declares a
MIME header (ContentType). If that is not the case, the
result is sometimes an empty stream. That depends on
the message content itself.
Per spec, when a MIME header is not specified, it must
assume a default (application/octet-stream).
The problem is that the class searches for a ':'. It
should, instead, do a proper MIME parsing.