Ok, tossed out TrafficMask, wrote my own CaptureLogFilter, and still
have the same problems I originally came to this list to try to find a
clue about....
I have an app that talks with more hardware than we can afford to keep
in house, so it has a simulator mode that reads data & script commands
from a source file and pretends to be one device or another. Each of
these simulations uses (used) a VmPipe connection. I've got two
detectable symptoms:
1) A session.write() call from the simulation code's engine thread does
not return until the data included in the write() is successfully
decoded.
2) If the data in the write() call is such that the MessageDecoder(s)
return NEED_DATA, the parent Mina object (CumulativeProtocolDecoder?)
repeatedly calls the MessageDecoder's decode() method with the same data
over and over and over and over and over and over ......... until
canceled by external forces.
Am I the only one that has seen this kind of behavior??? Is it
unique to VmPipe connections or indicative of a deeper problem????
Is there a work-around besides ensuring that no single session.write()
call results in anything more or less than a perfectly decodable, single
"packet" however the lower-level protocol may define that word??
Thanks in advance,
boB
Emmanuel Lecharny wrote:
boB Gage wrote:
I just upgraded from Mina 2.0.0M2 to M4 and ran into some issues I
didn't expect. Neither is listed in the M4 change notes. I don't
see any change notes from M3 to check.
1) There is no more TrafficMask object ??
We used to set our desired traffic to TrafficMask.ALL, just
commented that code out
The TrafficMask class was unusable as is. We decided to removed it
from the core. It has been removed on nov, 5th.
2) LoggingFilter object no longer has a log() method ????
We had overridden log() to impose our own format creating a
complete data capture log (Mina default format only showed first N
bytes)
The log() methods are now private. They are not mean to be exposed.
Would you have to log specific information, then I think the best
would be to write your own log filter, and push it to the chain. You
can even copy/paste the current loggingFilter, change what you need,
and inject it into the chain.
I'm hoping I can just ignore the TrafficMask issue. But our
LoggingFilter change was in response to a specific need (complete
data capture in log) that Mina was not giving us. The new
LoggingFilter has nothing that looks like a log() method at all.
Any comments or suggestions are appreciated!!! boB
