You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lens.apache.org by Pranav Kumar Agarwal <pr...@gmail.com> on 2015/11/02 14:52:32 UTC
LensClient.isConnectionOpen behavior
Hi All,
I can see LensClient.isConnectionOpen just checks if the connection was
ever established with the LensServer. However in my opinion it should
rather make a call to Session service and then check if the Hive session
is still valid in HiveSessionService.java.
Also, In HiveSessionService I can see that removal of the key from
SESSION_MAP happens only when an explicit call to closeSession is made,
so isOpen method in HiveSessionService won't work as is, but we should
rather query cliService to verify if the session is indeed valid.
Thoughts?
If there are no objections to the proposed change in behavior then I'll
file the jira.
Regards,
-Pranav.
Re: LensClient.isConnectionOpen behavior
Posted by "amareshwarisr ." <am...@gmail.com>.
I would say all client api should handle 410 and re-establish connection
and call the method again upon 410.
Regd, isConnectionOpen(), we should document the fact that this should not
be called for each api, as it would be two round trips and call it when
user requires such a check. Fixing isConnectionOpen to go to server and
check if it is valid, should be fine.
On Tue, Nov 3, 2015 at 5:14 PM, Pranav Kumar Agarwal <pr...@gmail.com>
wrote:
> Thanks for the quick response. I should have checked jira's more
> thoroughly.
>
> my 2 cents:
>
> Having an API LensClient.isConnectionOpen that doesn't return "false" when
> the the connection is closed sounds like an issue to me. As mentioned by
> Rajat in the jira, isConnectionOpen API can return 410 when the connection
> needs to be re-established.
>
> regarding the usecase: It is available as a LensClient API for the users
> to invoke LensInterpreter (i.e via lens-cli) from Zeppelin or for that
> matter using lens api. Its upto the API implementer to decide on how they
> implement their use-case i.e. whether they would like to handle using 410
> status code or by making two round-trips.
>
> In my Spark integration I want to check if the LensConnection is really
> open after a long inactivity on spark-shell rather than handling 410 at
> multiple places.
>
> Quite honestly I can add code to handle 410 as well. Either way is OK.
>
> Regards,
> -Pranav.
>
>
> On 03/11/15 10:50 am, amareshwarisr . wrote:
>
>> Can we understand usecases of this api?
>>
>> Why is LensClient.isConnectionOpen required? Are we suggesting users
>> should
>> call this for any api call? If that is required, for every call user has
>> to
>> do two round trips to server.
>>
>> Right now, all api takes session handle and returns 410 if session is
>> expired - upon which user can open a new session and try the call again. I
>> think that is a better option than providing an api for is current
>> session
>> valid or not.
>>
>> I see there is already some discussion on
>> https://issues.apache.org/jira/browse/LENS-794 regarding this. Please
>> check
>> if it makes sense.
>>
>> Thanks
>> Amareshwari
>>
>> On Mon, Nov 2, 2015 at 7:22 PM, Pranav Kumar Agarwal <pr...@gmail.com>
>> wrote:
>>
>> Hi All,
>>>
>>> I can see LensClient.isConnectionOpen just checks if the connection was
>>> ever established with the LensServer. However in my opinion it should
>>> rather make a call to Session service and then check if the Hive session
>>> is
>>> still valid in HiveSessionService.java.
>>>
>>> Also, In HiveSessionService I can see that removal of the key from
>>> SESSION_MAP happens only when an explicit call to closeSession is made,
>>> so
>>> isOpen method in HiveSessionService won't work as is, but we should
>>> rather
>>> query cliService to verify if the session is indeed valid.
>>>
>>> Thoughts?
>>>
>>> If there are no objections to the proposed change in behavior then I'll
>>> file the jira.
>>>
>>> Regards,
>>> -Pranav.
>>>
>>>
>
Re: LensClient.isConnectionOpen behavior
Posted by Pranav Kumar Agarwal <pr...@gmail.com>.
Thanks for the quick response. I should have checked jira's more thoroughly.
my 2 cents:
Having an API LensClient.isConnectionOpen that doesn't return "false"
when the the connection is closed sounds like an issue to me. As
mentioned by Rajat in the jira, isConnectionOpen API can return 410 when
the connection needs to be re-established.
regarding the usecase: It is available as a LensClient API for the users
to invoke LensInterpreter (i.e via lens-cli) from Zeppelin or for that
matter using lens api. Its upto the API implementer to decide on how
they implement their use-case i.e. whether they would like to handle
using 410 status code or by making two round-trips.
In my Spark integration I want to check if the LensConnection is really
open after a long inactivity on spark-shell rather than handling 410 at
multiple places.
Quite honestly I can add code to handle 410 as well. Either way is OK.
Regards,
-Pranav.
On 03/11/15 10:50 am, amareshwarisr . wrote:
> Can we understand usecases of this api?
>
> Why is LensClient.isConnectionOpen required? Are we suggesting users should
> call this for any api call? If that is required, for every call user has to
> do two round trips to server.
>
> Right now, all api takes session handle and returns 410 if session is
> expired - upon which user can open a new session and try the call again. I
> think that is a better option than providing an api for is current session
> valid or not.
>
> I see there is already some discussion on
> https://issues.apache.org/jira/browse/LENS-794 regarding this. Please check
> if it makes sense.
>
> Thanks
> Amareshwari
>
> On Mon, Nov 2, 2015 at 7:22 PM, Pranav Kumar Agarwal <pr...@gmail.com>
> wrote:
>
>> Hi All,
>>
>> I can see LensClient.isConnectionOpen just checks if the connection was
>> ever established with the LensServer. However in my opinion it should
>> rather make a call to Session service and then check if the Hive session is
>> still valid in HiveSessionService.java.
>>
>> Also, In HiveSessionService I can see that removal of the key from
>> SESSION_MAP happens only when an explicit call to closeSession is made, so
>> isOpen method in HiveSessionService won't work as is, but we should rather
>> query cliService to verify if the session is indeed valid.
>>
>> Thoughts?
>>
>> If there are no objections to the proposed change in behavior then I'll
>> file the jira.
>>
>> Regards,
>> -Pranav.
>>
Re: LensClient.isConnectionOpen behavior
Posted by "amareshwarisr ." <am...@gmail.com>.
Can we understand usecases of this api?
Why is LensClient.isConnectionOpen required? Are we suggesting users should
call this for any api call? If that is required, for every call user has to
do two round trips to server.
Right now, all api takes session handle and returns 410 if session is
expired - upon which user can open a new session and try the call again. I
think that is a better option than providing an api for is current session
valid or not.
I see there is already some discussion on
https://issues.apache.org/jira/browse/LENS-794 regarding this. Please check
if it makes sense.
Thanks
Amareshwari
On Mon, Nov 2, 2015 at 7:22 PM, Pranav Kumar Agarwal <pr...@gmail.com>
wrote:
> Hi All,
>
> I can see LensClient.isConnectionOpen just checks if the connection was
> ever established with the LensServer. However in my opinion it should
> rather make a call to Session service and then check if the Hive session is
> still valid in HiveSessionService.java.
>
> Also, In HiveSessionService I can see that removal of the key from
> SESSION_MAP happens only when an explicit call to closeSession is made, so
> isOpen method in HiveSessionService won't work as is, but we should rather
> query cliService to verify if the session is indeed valid.
>
> Thoughts?
>
> If there are no objections to the proposed change in behavior then I'll
> file the jira.
>
> Regards,
> -Pranav.
>