Logging when using the SSLFilter
Hi Very simple question. How can I change the logging level in SessionLog? Ta. -- Frederic P. Soulier PGP Key available on http://keyserver.pgp.com Key fingerprint = 49A6 8E8E 4230 8D41 1ADE B649 3203 1DD2 BA67 00ED
Re: Logging when using the SSLFilter
Ok thx will try tomorrow. On 7 Jul 2008, at 19:05, Alex Karasulu wrote: Oooops On Mon, Jul 7, 2008 at 2:04 PM, Alex Karasulu [EMAIL PROTECTED] wrote: Many options in log4j.properties. Try, log4j.logger.org.apache.mina.session.SessionLog=DEBUG Forgot =DEBUG or whatever level you like. Alex On Mon, Jul 7, 2008 at 1:48 PM, Frederic Soulier [EMAIL PROTECTED] wrote: Hi Very simple question. How can I change the logging level in SessionLog? Ta. -- Frederic P. Soulier PGP Key available on http://keyserver.pgp.com Key fingerprint = 49A6 8E8E 4230 8D41 1ADE B649 3203 1DD2 BA67 00ED -- Frederic P. Soulier PGP Key available on http://keyserver.pgp.com Key fingerprint = 49A6 8E8E 4230 8D41 1ADE B649 3203 1DD2 BA67 00ED
Re: CumulativeProtocolDecoder and UDP
Hi Trustin
Thx for your answer. It makes sense.
In our case UDP messages from clients are guaranteed to fit in 1 UDP
packet therefore the fact that UDP packet #2 may arrive before UDP
packet #1 is not relevant. At our level we just get message #2 before
message #1 and they are completely independant.
Obviously should the need arise to have larger messages from the
client we'll have to reconstruct the messages using UDP packets in
the right order.
The 2nd interesting finding which is more disconcerting is that using
MINA 1.1.3 there's effectively no accumulation by the
CumulativeProtocolDecoder for UDP traffic.
We skipped MINA 1.1.4 because of an issue with ProtocolCodecExection
I reported.
With MINA 1.1.5 the ProtocolCodecException works as per 1.1.3 but the
CumulativeProtocolDecoder now accumulates data for UDP!
Our app using 1.1.3 -- no accumulation for UDP
Our app using 1.1.4 -- accumulation for UDP
Could you confirm this change of behaviour?
On 13 Dec 2007, at 04:07, Trustin Lee wrote:
It's no use to use CumulativeProtocolDecoder in UDP because UDP never
guarantees the order of packets. Messages can be mixed up. :)
HTH,
Trustin
On Dec 12, 2007 4:27 AM, Frederic Soulier
[EMAIL PROTECTED] wrote:
Hi
I have an issue with Datagrams and the CumulativeProtocolDecoder
which doesn't seem to cumulate!
(working just fine with TCP).
I have a Decoder extending CumulativeProtocolDecoder.
protected boolean doDecode(IoSession session, ByteBuffer in,
ProtocolDecoderOutput out)
throws Exception
{
int startIndex = in.position(); // Save buffer position
boolean done = doDecodeWithoutBackingUp(session, in, out);
if (!done)
{
// Reset buffer to start as-if doDecodeWithoutBackingUp
had never run
in.position(startIndex);
}
return done;
}
protected boolean doDecodeWithoutBackingUp(IoSession ioSession,
ByteBuffer in, ProtocolDecoderOutput out)
throws Exception
{
if (in.remaining() TYPE_SIZE)
{
return false; // Need more data, we don't have the type
of the message
}
else
{
type = in.get();
if (type == TYPE_MSG)
{
if (in.remaining() TRANSACTION_ID_SIZE)
{
return false; // Need more data, we don't have
the transaction id
}
else
{
transactionId = in.getInt();
// do we have the message length?
if (in.remaining()
CodecUtils.MESSAGE_LENGTH_SIZE)
{
return false; // Need more data, we
don't have
the message length
}
else
{
int dataLength = in.getInt(); // Read
4-byte
int data length
// do we have all the data?
if (in.remaining() dataLength)
{
// Here we're already read 9
bytes (1 byte + 1 int + 1 int) but
== // we don't have all we need so
we return false and next time
// around we'll have more
return false; // Need more data,
we don't have the complete data
}
else
{
** HERE WE PROCESS A FULL
MESSAGE **
return true; // Please carry
on giving
us more data to decode
}
}
}
}
else
{
throw new MySuperDuperException();
}
}
}
The buffer (in.remaining = 30)
I read 9 bytes from the buffer to be able to decide whether to read
more or not.
in.remaining = 20 but my data length is 50 so I need more bytes and
return false.
Another datagram is received in the meantime, I expect the new
datagram to be accumulated behind what I haven't processed
(considering I returned true).
Instead I only get the new datagram and the previous stuff I haven't
processed yet is gone to the big bit bucket in the sky!
Is the Cumulative stuff supposed to work with UDP the same way it
works with TCP? As I wrote at the top it works prefectly with TCP.
Thx.
--
Frederic P. Soulier
OpenPGP key available on http://pgpkeys.mit.edu/
1024D/BA6700ED 49A6 8E8E 4230 8D41 1ADE B649 3203 1DD2 BA67 00ED
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
--
Frederic P. Soulier
OpenPGP key available on http://pgpkeys.mit.edu/
1024D/BA6700ED 49A6 8E8E 4230 8D41 1ADE B649 3203 1DD2 BA67 00ED
CumulativeProtocolDecoder and UDP
Hi
I have an issue with Datagrams and the CumulativeProtocolDecoder
which doesn't seem to cumulate!
(working just fine with TCP).
I have a Decoder extending CumulativeProtocolDecoder.
protected boolean doDecode(IoSession session, ByteBuffer in,
ProtocolDecoderOutput out)
throws Exception
{
int startIndex = in.position(); // Save buffer position
boolean done = doDecodeWithoutBackingUp(session, in, out);
if (!done)
{
// Reset buffer to start as-if doDecodeWithoutBackingUp
had never run
in.position(startIndex);
}
return done;
}
protected boolean doDecodeWithoutBackingUp(IoSession ioSession,
ByteBuffer in, ProtocolDecoderOutput out)
throws Exception
{
if (in.remaining() TYPE_SIZE)
{
return false; // Need more data, we don't have the type
of the message
}
else
{
type = in.get();
if (type == TYPE_MSG)
{
if (in.remaining() TRANSACTION_ID_SIZE)
{
return false; // Need more data, we don't have
the transaction id
}
else
{
transactionId = in.getInt();
// do we have the message length?
if (in.remaining()
CodecUtils.MESSAGE_LENGTH_SIZE)
{
return false; // Need more data, we don't have
the message length
}
else
{
int dataLength = in.getInt(); // Read 4-byte
int data length
// do we have all the data?
if (in.remaining() dataLength)
{
// Here we're already read 9
bytes (1 byte + 1 int + 1 int) but
== // we don't have all we need so
we return false and next time
// around we'll have more
return false; // Need more data,
we don't have the complete data
}
else
{
** HERE WE PROCESS A FULL
MESSAGE **
return true; // Please carry on giving
us more data to decode
}
}
}
}
else
{
throw new MySuperDuperException();
}
}
}
The buffer (in.remaining = 30)
I read 9 bytes from the buffer to be able to decide whether to read
more or not.
in.remaining = 20 but my data length is 50 so I need more bytes and
return false.
Another datagram is received in the meantime, I expect the new
datagram to be accumulated behind what I haven't processed
(considering I returned true).
Instead I only get the new datagram and the previous stuff I haven't
processed yet is gone to the big bit bucket in the sky!
Is the Cumulative stuff supposed to work with UDP the same way it
works with TCP? As I wrote at the top it works prefectly with TCP.
Thx.
--
Frederic P. Soulier
OpenPGP key available on http://pgpkeys.mit.edu/
1024D/BA6700ED 49A6 8E8E 4230 8D41 1ADE B649 3203 1DD2 BA67 00ED
Re: Issue upgrading from 1.1.3 to 1.1.4
Hi Trustin
Thx for looking into this.
I think having a way to define the behaviour when a
ProtocolDecoderException is thrown (carry on decoding or stop) would
be just fine.
On 1 Nov 2007, at 13:44, Trustin Lee wrote:
On 11/1/07, Trustin Lee [EMAIL PROTECTED] wrote:
Hi Frederic,
On 11/1/07, Frederic Soulier [EMAIL PROTECTED] wrote:
Hi
We are seeing a really odd behaviour after upgrading yesterday to
1.1.4 from 1.1.3
Basically if we see an invalid message (we deem it invalid as
part of
our business logic) we just throw an exception and close the
ioSession.
It worked perfectly up to 1.1.3 and is completely buggered in
1.1.4...
In 1.1.4 we get tons of exception because of the newly introduced
while loop (while (in.hasRemaining())) in the try {} catch block of
the ProtocolCodecFilter messageReceived(...)
snip/
I can't see anything related to this change in the changelog and the
reason why.
This is a major regression considering that if you have a message
that is 1000 bytes long and the 1st byte is deemed invalid and you
want to close this ioSession you will get 1000 times the same
exception that fills up MBs of logs in seconds!!!
Right now we're going back to 1.1.3
First off, I apologize for your inconvenience. I had to be more
careful. :-(
The change occurred while I fix DoS bug in TextLineDecoder. The
latest TextLineDecoder now can keep decoding incoming data even if
any
broken data is received (i.e. too long line). With the
ProtocolCodecFilter implementation in 1.1.3, it was not able to
continue decoding until any new data is received even if there was
more than one line in the previous buffer. This means, if client is
sending a too long line + a short line, the messageReceived event for
the short line might not be fired. That was why inserted a loop.
I'd better revert the change back in 1.1.5 and 1.0.8, and provide a
way to take care of TextLineDecoder case in 2.0.0. We could
provide a
subclass of ProtocolDecoderException such as
RecoverableProtocolDecoderException so ProtocolCodecFilter can decide
to loop or not. WDYT?
I filed the related JIRA issues in case you want to keep track of
the problem.
https://issues.apache.org/jira/browse/DIRMINA-465
https://issues.apache.org/jira/browse/DIRMINA-466
HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
--
Frederic P. Soulier
OpenPGP key available on http://pgpkeys.mit.edu/
1024D/BA6700ED 49A6 8E8E 4230 8D41 1ADE B649 3203 1DD2 BA67 00ED
UDP
Hi We've been pretty successful at implementing a complex message protocol using MINA (0.9.3 then 1.0.x) over TCP. We're now considering implementing the same protocol over UDP. So my first questions are: - is the UDP implementation in MINA as solid as the TCP one? - is there any magic going on under the hood I should be aware of? (I assume that the UDP packets will arrive in any order and that we'll have to implement our own re-ordering mechanism) Thx. -- Frederic Soulier [EMAIL PROTECTED] OpenPGP key available on http://www.keyserver.net 1024D/BA6700ED 49A6 8E8E 4230 8D41 1ADE B649 3203 1DD2 BA67 00ED
