You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Joshua Portway <jo...@stain.org> on 2006/02/22 16:44:25 UTC
zero length packet problem
Hi,
I'm sorry - sure I read the answer to this on the mailing list
before (at least something about it) but the archive search on the
apahce site isn't working at the moment. I'm writing my own codec,
and keep getting a zero length packet sent at the end of each
message. This seems to be caused by the encoderOut.flush() call at
the end of ProtocolCodecFiler.filterWrite(). My codec generally does
quite a few ProtocolCodecFiler.merge() and ProtocolCodecFiler.flush()
calls during the actual encoding process itself, since I need control
of the actual packets that get sent (it's a UDP protocol to some
embedded hardware). Are my own flush call causing the problem ? Maybe
I should avoid doing a flush for the last packet ?
I'm using the in-VM transport - haven't tried it with a proper
network transport yet.
Mina 0.9.0
any idea what I'm doing wrong ?
josh
Re: Compression
Posted by Vinod Panicker <vi...@gmail.com>.
On 3/2/06, fedechicco@gmail.com <fe...@gmail.com> wrote:
> You are a god mister 8)
> I was already trying to write my own implementation but I started from the
> scratch, so I was lost.
https://issues.apache.org/jira/browse/DIRMINA-179
I've attached the patch file. You will also need jzlib-1.0.7.jar
I dont know if I'm supposed to upload that to jira as well. You can
make your own jar after downloading the source from here -
http://www.jcraft.com/jzlib/
Regards,
Vinod.
Re: Compression
Posted by fe...@gmail.com.
You are a god mister 8)
I was already trying to write my own implementation but I started from the
scratch, so I was lost.
Thanks a lot!
----- Original Message -----
From: "Vinod Panicker" <vi...@gmail.com>
To: <mi...@directory.apache.org>
Sent: Thursday, March 02, 2006 10:46 AM
Subject: Re: Compression
On 3/1/06, fedechicco@gmail.com <fe...@gmail.com> wrote:
> Hi everybody, I'm looking on the internet to find compression classes that
> can be used with java.nio, but I can't find them.
>
> I only want to create an IoFilter that can deflate and inflate data on the
> fly when it arrives, because I have to send many repetition over the same
> connection in my protocol, and java.zip is uneffective in my case ( many
> little repetitive packets).
>
> Has somebody any idea about what I can do?
> I have find jzlib but it seems like if it is no more in development.
Seems like this is your lucky day. I've just finished implementing a
compression filter with MINA. Had sent it to trustin for review
yesterday. I still have to open a JIRA issue since I've not finished
testing it out. You're welcome to try it out. Let me open a JIRA
issue and attach the diff file.
Regards,
Vinod.
Re: Compression
Posted by Vinod Panicker <vi...@gmail.com>.
On 3/1/06, fedechicco@gmail.com <fe...@gmail.com> wrote:
> Hi everybody, I'm looking on the internet to find compression classes that
> can be used with java.nio, but I can't find them.
>
> I only want to create an IoFilter that can deflate and inflate data on the
> fly when it arrives, because I have to send many repetition over the same
> connection in my protocol, and java.zip is uneffective in my case ( many
> little repetitive packets).
>
> Has somebody any idea about what I can do?
> I have find jzlib but it seems like if it is no more in development.
Seems like this is your lucky day. I've just finished implementing a
compression filter with MINA. Had sent it to trustin for review
yesterday. I still have to open a JIRA issue since I've not finished
testing it out. You're welcome to try it out. Let me open a JIRA
issue and attach the diff file.
Regards,
Vinod.
Compression
Posted by fe...@gmail.com.
Hi everybody, I'm looking on the internet to find compression classes that
can be used with java.nio, but I can't find them.
I only want to create an IoFilter that can deflate and inflate data on the
fly when it arrives, because I have to send many repetition over the same
connection in my protocol, and java.zip is uneffective in my case ( many
little repetitive packets).
Has somebody any idea about what I can do?
I have find jzlib but it seems like if it is no more in development.
thanks to all!
Re: zero length packet problem
Posted by Trustin Lee <tr...@gmail.com>.
It should be fixed now.
On 2/24/06, Trustin Lee <tr...@gmail.com> wrote:
>
> On 2/23/06, Joshua Portway <jo...@stain.org> wrote:
>
> > Hi,
> > I'm sorry - sure I read the answer to this on the mailing list
> > before (at least something about it) but the archive search on the
> > apahce site isn't working at the moment. I'm writing my own codec,
> > and keep getting a zero length packet sent at the end of each
> > message. This seems to be caused by the encoderOut.flush() call at
> > the end of ProtocolCodecFiler.filterWrite(). My codec generally does
> > quite a few ProtocolCodecFiler.merge () and ProtocolCodecFiler.flush()
> > calls during the actual encoding process itself, since I need control
> > of the actual packets that get sent (it's a UDP protocol to some
> > embedded hardware). Are my own flush call causing the problem ? Maybe
> > I should avoid doing a flush for the last packet ?
> >
> > I'm using the in-VM transport - haven't tried it with a proper
> > network transport yet.
> > Mina 0.9.0
> >
> > any idea what I'm doing wrong ?
>
>
> It is a bug. Please track this bug here:
>
> http://issues.apache.org/jira/browse/DIRMINA-177
>
> Thanks,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP key fingerprints:
> * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
> * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: zero length packet problem
Posted by Trustin Lee <tr...@gmail.com>.
On 2/23/06, Joshua Portway <jo...@stain.org> wrote:
>
> Hi,
> I'm sorry - sure I read the answer to this on the mailing list
> before (at least something about it) but the archive search on the
> apahce site isn't working at the moment. I'm writing my own codec,
> and keep getting a zero length packet sent at the end of each
> message. This seems to be caused by the encoderOut.flush() call at
> the end of ProtocolCodecFiler.filterWrite(). My codec generally does
> quite a few ProtocolCodecFiler.merge() and ProtocolCodecFiler.flush()
> calls during the actual encoding process itself, since I need control
> of the actual packets that get sent (it's a UDP protocol to some
> embedded hardware). Are my own flush call causing the problem ? Maybe
> I should avoid doing a flush for the last packet ?
>
> I'm using the in-VM transport - haven't tried it with a proper
> network transport yet.
> Mina 0.9.0
>
> any idea what I'm doing wrong ?
It is a bug. Please track this bug here:
http://issues.apache.org/jira/browse/DIRMINA-177
Thanks,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6