You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@mina.apache.org by boB Gage <bg...@ekosystems.com> on 2008/12/31 16:04:12 UTC
LoggingFilter.log ??
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
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)
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
Re: LoggingFilter.log ??
Posted by boB Gage <bg...@ekosystems.com>.
I think we might've had the problem, and not realized it. But I
coulda sworn I'd tested the trigger condition ("packet" in my simulation
data file split across multiple source lines) long before seeing this
issue...
The thread stealing wasn't even detected until long after we'd triggered
the endless loop. I saw the loop behavior (as a unknown crash
condition) before but didn't have the time to deal with it, so just
modified that simulation's source file to avoid the "partial packet"
trigger (NEED_DATA from the MessageDecoders). When I started to track
it and work a way around I ran into these issues.
I **think** that since we're using MessageDecoder descendants assigned
from DemuxingProtocolCodecFactory descendants that we've already gotten
the CumulativeProtocolDecoder as part of our ancestor tree -- at least,
that attempt didn't change the behavior in any detectable way...
I'm in the process of re-writing the simulator to use TCP/IP sockets
instead of VmPipe objects to see if that helps any.
Thanks!!
boB
Maarten Bosteels wrote:
> Hi BoB,
>
> You didn't have these issues with Mina 2.0.0M2 ?
>
> Maarten
>
> On Mon, Jan 5, 2009 at 4:06 PM, boB Gage <bg...@ekosystems.com> wrote:
>
>
>> 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
>>>>
>>>>
>>>>
>>>
>
>
Re: LoggingFilter.log ??
Posted by Maarten Bosteels <mb...@gmail.com>.
Hi BoB,
You didn't have these issues with Mina 2.0.0M2 ?
Maarten
On Mon, Jan 5, 2009 at 4:06 PM, boB Gage <bg...@ekosystems.com> wrote:
> 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
>>>
>>>
>>
>>
Re: LoggingFilter.log ??
Posted by boB Gage <bg...@ekosystems.com>.
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
>>
>
>
Re: LoggingFilter.log ??
Posted by Emmanuel Lecharny <el...@gmail.com>.
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
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org