On 27.08.15 05:24, Ben-Yosef Efrat wrote:
>
> I don’t understand J
>
> You said otherwise handleRead will just carry onand also they might be
> run in parallel
>
> So, is there any way to prevent them running in parallel? I want the
> handleRead to continue without the handleClose to be called in the middle.
>
Right, imagine the situation, when you are in the middle of handRead()
in your Filter in one thread and the other thread at the same time is
writing something to the same connection. Suddenly the writer catches
IOException, meaning that the peer closed the connection, so it calls
connection.close(), which initiates handleClose event on a FilterChain.
By default Grizzly doesn't synchronize handleClose with any other event
processing, IMO it makes sense to notify Filters about closed connection
asap, and it's up to Filter to decide if it want to synchronize events
or not.
Thanks.
WBR,
Alexey.
> Thanks
>
> Efrat
>
> *From:*Oleksiy Stashok [mailto:oleksiy.stashok_at_oracle.com]
> *Sent:* Wednesday, August 26, 2015 2:14 AM
> *To:* users_at_grizzly.java.net
> *Subject:* Re: Close connection while handleRead()
>
> Hi,
>
> On 25.08.15 07:40, Ben-Yosef Efrat wrote:
>
> I have a question, what is supposed to happen when while in
> handleRead(), a connection is closed?
>
> It's up to the Filter code, if it explicitly checks if connection is
> closed - it may interrupt filter chain processing, otherwise
> handleRead will just carry on.
>
>
> Is the handleRead supposed to be finished and only then the handeClose
> will be called? will the handleClose be called at the time the
> connection is closed without waiting?
>
> No, there is no synchronization between handleRead and handleClose,
> they might be run in parallel.
>
>
> Same regarding the handleWrite.
>
> Same as handleRead.
>
> Thanks.
>
> WBR,
> Alexey.
>
> Thanks
>
> Efrat
>
> ------------------------------------------------------------------------
>
> “This e-mail message may contain confidential, commercial or
> privileged information that constitutes proprietary information of
> Comverse Inc. or its subsidiaries. If you are not the intended
> recipient of this message, you are hereby notified that any review,
> use or distribution of this information is absolutely prohibited and
> we request that you delete all copies and contact us by e-mailing to:
> security_at_comverse.com <mailto:security_at_comverse.com>. Thank You.”
>
> ------------------------------------------------------------------------
> “This e-mail message may contain confidential, commercial or
> privileged information that constitutes proprietary information of
> Comverse Inc. or its subsidiaries. If you are not the intended
> recipient of this message, you are hereby notified that any review,
> use or distribution of this information is absolutely prohibited and
> we request that you delete all copies and contact us by e-mailing to:
> security_at_comverse.com. Thank You.”