Le 22/05/2018 à 19:31, Jonathan Valliere a écrit :
> Or you could add IoBuffer#getHexDump(start, end)?
Clearly an option.
That would raise the question : do we need an helper class then ?
--
Emmanuel Lecharny
Symas.com
directory.apache.org
pEpkey.asc
Description: application/pgp-keys
Or you could add IoBuffer#getHexDump(start, end)?
On Tue, May 22, 2018 at 12:55 PM Emmanuel Lécharny
wrote:
>
>
> Le 22/05/2018 à 18:37, Jonathan Valliere a écrit :
> > I don’t think there is any benefit of having it public. It’s only useable
> > with IoBuffer and it’s built in to IoBuffer. Unl
Le 22/05/2018 à 18:37, Jonathan Valliere a écrit :
> I don’t think there is any benefit of having it public. It’s only useable
> with IoBuffer and it’s built in to IoBuffer. Unless someone added more
> functions to it which aren’t present in IoBuffer such as hex ranges then
> might as well leave
I don’t think there is any benefit of having it public. It’s only useable
with IoBuffer and it’s built in to IoBuffer. Unless someone added more
functions to it which aren’t present in IoBuffer such as hex ranges then
might as well leave it as is.
On Tue, May 22, 2018 at 10:53 AM Emmanuel Lécharn
Le 22/05/2018 à 16:04, Jonathan Valliere a écrit :
> Just made the commit so getHexDump() is now perfectly safe without having
> to create a duplicate.
Thanks for that !
One more thing : the IoBufferHexDumper class is package protected, which
is probably a bit limiting. It might be worthful to
Just made the commit so getHexDump() is now perfectly safe without having
to create a duplicate.
On Tue, May 22, 2018 at 9:59 AM, Emmanuel Lécharny
wrote:
>
>
> Le 22/05/2018 à 15:09, Jonathan Valliere a écrit :
> > Right, but the caveat is that the duplicate buffer shares the same memory
> > sp
Le 22/05/2018 à 15:09, Jonathan Valliere a écrit :
> Right, but the caveat is that the duplicate buffer shares the same memory
> space.
Correct. As soon as you don't change the internal byte [], you are fine
though. Dumping a duplicate should thenalways be fine.
Calling duplicate then changi
Done
I'll update getHexDump to be non-modifying right now
On Tue, May 22, 2018 at 9:09 AM, Jonathan Valliere
wrote:
> Right, but the caveat is that the duplicate buffer shares the same memory
> space. Calling duplicate then changing the contents would be a no-no.
> Without drilling down and paying a
Right, but the caveat is that the duplicate buffer shares the same memory
space. Calling duplicate then changing the contents would be a no-no.
Without drilling down and paying attention, it would be easy to think that
duplicate actually duplicates the buffer instead of creating a slice.
On Tue,
Le 22/05/2018 à 14:02, Jonathan Valliere a écrit :
> Duplicating the buffer most likely temporarily moves the position also. If
> you submit a buffer to be written, don’t do anything with it until after it
> it written.
ByteBuffer.duplicate() - which is called by IoBuffer.duplicate() -
creates
Duplicating the buffer most likely temporarily moves the position also. If
you submit a buffer to be written, don’t do anything with it until after it
it written.
On Tue, May 22, 2018 at 5:55 AM Emmanuel Lécharny
wrote:
>
>
> Le 22/05/2018 à 11:17, rexxar a écrit :
> > Hi,Emmanuel
> >
> >Th
Le 22/05/2018 à 11:17, rexxar a écrit :
> Hi,Emmanuel
>
>Thank you very much for your Explanation and Suggest。But I still have
> doubts about this ：
>
> the IoBuffer.getHexDump() method do move the position while dumping the
> content，but it
>
> recover it finally。It seems no other thread
Hi,Emmanuel
Thank you very much for your Explanation and Suggest。But I still have
doubts about this ：
the IoBuffer.getHexDump() method do move the position while dumping the
content，but it
recover it finally。It seems no other thread will operate the IoBuffer during
this period，right?
Can a
Hi,
the IoBuffer.getHexDump() method does not copy the IoBuffer, and will
move the position while dumping the content.
It's clearly not the smartes utility function, as you can imagine...
Anyway, you have to copy the buffer (duplicate() function) you want to
dump before dumping it, to avoid any
Hi，
here is the Implement of encode"
@Override
public void encode(IoSession session, Object message,
ProtocolEncoderOutput
out) throws Exception {
IoBuffer buf = IoBuffer.allocate(100);
buf.setAutoExpand(true);
NetMessage msg = (NetMessage) message;
Hi,
Le 21/05/2018 à 15:36, rexxar a écrit :
> hi pete:
> I still come across the same IoBuffer "mark" problem with mina2.0.16 。
Do you have a piece of code demonstrating the problem you have ?
--
Emmanuel Lecharny
Symas.com
directory.apache.org
pEpkey.asc
Description: application/pg
hi pete:
I still come across the same IoBuffer "mark" problem with mina2.0.16 。It
happened occasionally when I add a log to dump（use getHexDump()） the
iobuffer in the encoder fliter 。 Have you solved this problem since this
problem was put forward in 2008? Have you received other cases with th
On Jun 23, 2008, at 10:39 AM, Yigal Rachman wrote:
Sorry for my slow response - I have just returned from a (too short)
vacation.
Thank you for looking into this.
I think you are correct in believing that the original problem is a
MINA bug. I ran a soak test that does not involve extra thr
Hi, Pete:
Sorry for my slow response - I have just returned from a (too short)
vacation.
Thank you for looking into this.
I think you are correct in believing that the original problem is a MINA
bug. I ran a soak test that does not involve extra threads to see
whether the IoBuffer "mark" p
On May 27, 2008, at 3:27 PM, Yigal Rachman wrote:
I asked about this in February and have managed to move ahead
without a proper solution. However, I am seeing glitches that point
to synchronizing problems, so I would greatly appreciate any help
that you could offer me. To recap: how do I
Hi, Folks:
I asked about this in February and have managed to move ahead without a
proper solution. However, I am seeing glitches that point to
synchronizing problems, so I would greatly appreciate any help that you
could offer me. To recap: how do I synchronize the operation of a
thread ex
22 matches
Mail list logo
