disableIOEvent read

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

disableIOEvent read

Ben-Yosef Efrat

Hello

 

I want to simulate a synchronic behavior so when client issues two commands at once, when the first command is still executing. Flow is:

 

1.       Client issues command

2.       On handleRead() I perform, connection. disableIOEvent(IOEvent.READ)

3.       Command is executing (sleeps)

4.       Client issues another command – I would expect that the handleRead() will not be called until connection. enableIOEvent(IOEvent.READ) is called. However, the handleRead() is called anyway.

 

Am I missing something?

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: [hidden email]. Thank You.”
Reply | Threaded
Open this post in threaded view
|

Re: disableIOEvent read

oleksiys
Administrator
Hi,

as I understand you run "command" in the separate thread, not in the one FilterChain was executed, is it correct?
Normally there's no need to deal directly with disableIOEvent/enableIOEvent, in 99% of cases you can control that with FilterChain NextAction commands returned from handleXXX methods.

Take a look at this sample:
https://github.com/GrizzlyNIO/grizzly-mirror/blob/2.3.x/samples/framework-samples/src/main/java/org/glassfish/grizzly/samples/echo/EchoFilterAsync.java

Pls. let me know if you have more questions.

WBR,
Alexey.

On 04.02.15 06:42, Ben-Yosef Efrat wrote:

Hello

 

I want to simulate a synchronic behavior so when client issues two commands at once, when the first command is still executing. Flow is:

 

1.       Client issues command

2.       On handleRead() I perform, connection. disableIOEvent(IOEvent.READ)

3.       Command is executing (sleeps)

4.       Client issues another command – I would expect that the handleRead() will not be called until connection. enableIOEvent(IOEvent.READ) is called. However, the handleRead() is called anyway.

 

Am I missing something?

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: [hidden email]. Thank You.”

Reply | Threaded
Open this post in threaded view
|

RE: disableIOEvent read

Ben-Yosef Efrat

Thanks Alexey

 

I will try your suggestion of solution, however I still want to understand why my solution does not work.

 

We disable the IORead on the handleRead() on the same thread invoked by Grizzly (we don’t activate any other threads on our own). Why doesn’t it block the handleRead() for the next command although we didn’t enable the IORead?

Note that both disable/enable and the commands are applied on the same connection.

 

Thanks

Efrat

 

From: Oleksiy Stashok [mailto:[hidden email]]
Sent: Wednesday, February 04, 2015 8:12 PM
To: [hidden email]
Subject: Re: disableIOEvent read

 

Hi,

as I understand you run "command" in the separate thread, not in the one FilterChain was executed, is it correct?
Normally there's no need to deal directly with disableIOEvent/enableIOEvent, in 99% of cases you can control that with FilterChain NextAction commands returned from handleXXX methods.

Take a look at this sample:
https://github.com/GrizzlyNIO/grizzly-mirror/blob/2.3.x/samples/framework-samples/src/main/java/org/glassfish/grizzly/samples/echo/EchoFilterAsync.java

Pls. let me know if you have more questions.

WBR,
Alexey.

On 04.02.15 06:42, Ben-Yosef Efrat wrote:

Hello

 

I want to simulate a synchronic behavior so when client issues two commands at once, when the first command is still executing. Flow is:

 

1.       Client issues command

2.       On handleRead() I perform, connection. disableIOEvent(IOEvent.READ)

3.       Command is executing (sleeps)

4.       Client issues another command – I would expect that the handleRead() will not be called until connection. enableIOEvent(IOEvent.READ) is called. However, the handleRead() is called anyway.

 

Am I missing something?

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: [hidden email]. 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: [hidden email]. Thank You.”
Reply | Threaded
Open this post in threaded view
|

Re: disableIOEvent read

oleksiys
Administrator

On 05.02.15 07:38, Ben-Yosef Efrat wrote:

 

I will try your suggestion of solution, however I still want to understand why my solution does not work.

 

We disable the IORead on the handleRead() on the same thread invoked by Grizzly (we don’t activate any other threads on our own). Why doesn’t it block the handleRead() for the next command although we didn’t enable the IORead?

Note that both disable/enable and the commands are applied on the same connection.

Well, as I said by default enabling/disabling is automatically done by framework itself.
If you want to control disabling/enabling manually - you have to call this:
filterChainContext.getInternalContext().setManualIOEventControl();

before disabling the event.

Pls. let me know if it worked.

WBR,
Alexey.


 

Thanks

Efrat

 

From: Oleksiy Stashok [[hidden email]]
Sent: Wednesday, February 04, 2015 8:12 PM
To: [hidden email]
Subject: Re: disableIOEvent read

 

Hi,

as I understand you run "command" in the separate thread, not in the one FilterChain was executed, is it correct?
Normally there's no need to deal directly with disableIOEvent/enableIOEvent, in 99% of cases you can control that with FilterChain NextAction commands returned from handleXXX methods.

Take a look at this sample:
https://github.com/GrizzlyNIO/grizzly-mirror/blob/2.3.x/samples/framework-samples/src/main/java/org/glassfish/grizzly/samples/echo/EchoFilterAsync.java

Pls. let me know if you have more questions.

WBR,
Alexey.

On 04.02.15 06:42, Ben-Yosef Efrat wrote:

Hello

 

I want to simulate a synchronic behavior so when client issues two commands at once, when the first command is still executing. Flow is:

 

1.       Client issues command

2.       On handleRead() I perform, connection. disableIOEvent(IOEvent.READ)

3.       Command is executing (sleeps)

4.       Client issues another command – I would expect that the handleRead() will not be called until connection. enableIOEvent(IOEvent.READ) is called. However, the handleRead() is called anyway.

 

Am I missing something?

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: [hidden email]. 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: [hidden email]. Thank You.”