[ 
https://issues.apache.org/jira/browse/IGNITE-3138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422381#comment-15422381
 ] 

Vladislav Pyatkov edited comment on IGNITE-3138 at 8/16/16 8:02 AM:
--------------------------------------------------------------------

My point of view:
1) This check was did for the check are buffers flushing needed. And this can 
be skip at all (because buffer can by empty, if count of entry loaded per node 
divisible by {{bufSize}}, what unlikely).

2) Yes, а hang into a future it possible (this easy reproduce, if custom 
Reciver hangs). Future get method (which return from {{addData}}) need to 
invoke with timeout, even through timeout of Streamer is use.


was (Author: v.pyatkov):
My point of view:
1) This check was did for the check are buffers flushing needed. And this can 
be skip at all (because buffer can by empty, if count of entry loaded per node 
divisible by bufSize, what unlikely).

2) Yes, а hang into a future it possible (this easy reproduce, if custom 
Reciver hangs). Futere get method (which return from addData) need to invoke 
with timeout, even through timeout of Streamer is use.

> IgniteDataStreamer: failures are not shown on the streaming side
> ----------------------------------------------------------------
>
>                 Key: IGNITE-3138
>                 URL: https://issues.apache.org/jira/browse/IGNITE-3138
>             Project: Ignite
>          Issue Type: Bug
>            Reporter: Denis Magda
>            Assignee: Vladislav Pyatkov
>         Attachments: DataStreamerFailuresTest.java
>
>
> If an exception happens during the streaming, the side that streams the data 
> won't printed out anything in its logs even if IGNITE_QUIET set to false.
> This makes it's inconvenient to see whether there an issue happened during 
> the streaming or not.
> Suggested improvements:
> - print out errors that happened during the streaming on the streaming side;
> - Future that is returned from {{addData}} methods is not called in case of 
> error. This must be fixed. So that the user is able to write a custom logic 
> around this feature and process errors somehow.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to