Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id C56A6200CFE for ; Fri, 8 Sep 2017 19:14:56 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id C43D41609C0; Fri, 8 Sep 2017 17:14:56 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id BB4631609BE for ; Fri, 8 Sep 2017 19:14:55 +0200 (CEST) Received: (qmail 99099 invoked by uid 500); 8 Sep 2017 17:14:54 -0000 Mailing-List: contact user-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@ignite.apache.org Delivered-To: mailing list user@ignite.apache.org Received: (qmail 99089 invoked by uid 99); 8 Sep 2017 17:14:54 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Sep 2017 17:14:54 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id F31EA1A78A6 for ; Fri, 8 Sep 2017 17:14:53 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.401 X-Spam-Level: X-Spam-Status: No, score=-0.401 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id CPV0Rye9Su7L for ; Fri, 8 Sep 2017 17:14:52 +0000 (UTC) Received: from mail-wr0-f169.google.com (mail-wr0-f169.google.com [209.85.128.169]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id BE4735F5B3 for ; Fri, 8 Sep 2017 17:14:51 +0000 (UTC) Received: by mail-wr0-f169.google.com with SMTP id a43so5791530wrc.0 for ; Fri, 08 Sep 2017 10:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=v09ioVKyeTe6LrJO7kiWMI6XCJ7NMU5ip1u3wRy7D84=; b=QkV1QRECuFpWhMECX2w7eXcmpOZdoGzkYbvrWZn2unRkGHAYNDTOU+MCUUUT2fAUFD p8fFMAn+6Ome0w+2wgmDzjklk1Fcmq1Chzdp3sPsDaydQK7sFA6Px8CGovC6T2SHomhh cItNSXLej2vJEn3mwKwTPk75Za1dCmhG2Rg5FrqnatsZ8E91WYc0xZPgUwLwXMJsvmwV limY7NHkrY2DZ3E61hF/40q+AD2pqE64/GjUm87j5qQBSS7iDR3myeGN9v10BLeChyGM PbYb5V2fsf9gF69B9sq2Fepk31HFW+npT21OU3JxRfuwWgu9cdgF1XI1LU2j3KxTdcSA 4dqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=v09ioVKyeTe6LrJO7kiWMI6XCJ7NMU5ip1u3wRy7D84=; b=ECBRO08buMAQwwpNNoL29CpxOANHjceyDReqF6ogkjbUR1s5Z503uaz8ftQrZpEThZ rCtQtkekOrW0p+AnMEi7LUGIyZrTBo1xz4VrGMdZnOwp8bwBRzz5KPybuez3gFKb7ILB ecqQ+Ge2GA8zxO84UtcfzBnzLZVmaGDiSv1oB10Qe1lb8XUNe64MmkDe28xGEriyEY8e mQBPQ0Tl5ELrrWDoHXt9CaMm7wuXOebPsv7FYZne3CKGEll9+AsSmKOWi0jvMcTpBxt8 EmF8quVyPDvdzIfSPh/hmNVryu+BDQRFTgwked1fActXd782BX6nT9JchaRuzSh6mZra IFLg== X-Gm-Message-State: AHPjjUh2MGze6QdVk4O7/0QyPsUWZJOTwM1M8yOFvSUvFq5MI5J27wyV LAfNN1GqcTVLtPEZEaUoDM8/og7Pyzj4YBM= X-Google-Smtp-Source: ADKCNb70eHp8Xg7TndTw3YHNNiCk8XdaG8SQwcyXy2r4VmSJNk29IVhpZpFb3qKb+D5b1mJ+oF4rFdbpbogwxWvKv+I= X-Received: by 10.223.136.168 with SMTP id f37mr2634582wrf.191.1504890884833; Fri, 08 Sep 2017 10:14:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.74.204 with HTTP; Fri, 8 Sep 2017 10:14:14 -0700 (PDT) In-Reply-To: References: From: Michael Cherkasov Date: Fri, 8 Sep 2017 20:14:14 +0300 Message-ID: Subject: Re: Design question on the Ignite Web Session Clustering. To: user@ignite.apache.org Content-Type: multipart/alternative; boundary="001a1145278c9dd19b0558b0b681" archived-at: Fri, 08 Sep 2017 17:14:57 -0000 --001a1145278c9dd19b0558b0b681 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I answered in SO, I copy it here: """ if you have a local cache for sessions and sticky sessions why do you need to use ignite at all? However, It's better to go with ignite, your app will have HA, if some node is failed, the whole app still will work fine. I agree you should split app cluster and ignite cluster, however, I think you shouldn't care about connection problem about the server and client. This kind of problems should lead to 500 error, would you emulate main storage if you DB go down or you can't connect to it? """ Thanks, Mikhail. 2017-09-07 20:12 GMT+03:00 Shrikant Patel : > Hi All, > > > > I have design question about Ignite web session clustering. > > > > I have springboot app with UI. It clustered app ie multiple instance of s= pringboot app behind the load balancer. I am using org.apache.ignite.cache.= websession.WebSessionFilter()to intercept request and create\manage session= for any incoming request. > > > > I have 2 option > > > > 1. Embed the ignite node inside springboot app. So have these embedd= ed ignite node (on each springboot JVM) be part of cluster. This way reques= t session is replicated across the entire springboot cluster. On load balan= cer I don=E2=80=99t have to maintain the sticky connection. The request can= go to any app in round robin or least load algorithm. > > > > Few considerations > > a. Architect is simple. I don=E2=80=99t have worry about the cache b= eing down etc. > > b. Now the cache being embedded, its using CPU and memory from app j= vm. It has potential of starving my app of resources. > > > > 2. Have ignite cluster running outside of app JVM. So now I run clie= nt node in springboot app and connect to main ignite cluster. > > > > Few considerations > > > > a. For any reason, if the client node cannot connect to main ignite = cluster. Do I have to manage the session manually and then push those sessi= on manually at later point to the ignite cluster?? > > b. If I manage session locally I will need to have sticky connection= on the load balancer. Which I want to avoid if possible. > > > 1. I am leaning to approach 2, but want to make it simple. So if > client node cannot create session (override org.apache.ignite.cache= .websession.WebSessionFilter()) > it redirects user to page indicating the app is down or to another = app node > in the cluster. > > > > > > Are there any other design approach I can take? > > Am I overlooking anything in either approach? > > > > If you have dealt with it, please share your thoughts. > > > > Thanks in advance. > > Shri > > > This e-mail and its contents (to include attachments) are the property of > National Health Systems, Inc., its subsidiaries and affiliates, including > but not limited to Rx.com Community Healthcare Network, Inc. and its > subsidiaries, and may contain confidential and proprietary or privileged > information. If you are not the intended recipient of this e-mail, you ar= e > hereby notified that any unauthorized disclosure, copying, or distributio= n > of this e-mail or of its attachments, or the taking of any unauthorized > action based on information contained herein is strictly prohibited. > Unauthorized use of information contained herein may subject you to civil > and criminal prosecution and penalties. If you are not the intended > recipient, please immediately notify the sender by telephone at > 800-433-5719 or return e-mail and permanently delete the original e-mail. > --001a1145278c9dd19b0558b0b681 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I answered in SO, I copy it here:
"""
if you have a local cache for se= ssions and sticky sessions why do you need to use ignite at all?
=
However, It's better to go with ignite, your app will ha= ve HA, if some node is failed, the whole app still will work fine. I agree = you should split app cluster and ignite cluster, however, I think you shoul= dn't care about connection problem about the server and client. This ki= nd of problems should lead to 500 error, would you emulate main storage if = you DB go down or you can't connect to it?
""= "
Thanks,
Mikhail.

2017-09-07 20:12 GMT+03:00 Shrikant P= atel <SPatel@pdxinc.com>:

Hi All, <= /u>

=C2=A0

I have design quest= ion about Ignite web session clustering.

=C2=A0

I have springboot app with UI. It clustere=
d app ie multiple instance of springboot app behind the load balancer. I am=
 using org.apache.ignite.cache.websession.WebSessionFilter()to in=
tercept request and create\manage session for any incoming request. =

=C2=A0
I have 2 option 

=C2=A0


1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 Embed the ignite node inside springboot app. =
So have these embedded ignite node (on each springboot JVM) be part of clus=
ter. This way request session is replicated across the entire springboot cl=
uster. On load balancer I don=E2=80=99t have to maintain the sticky connect=
ion. The request can go to any app in round robin or least load algorithm. =



=C2=A0


Few considerations 


a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 Architect is simple. I don=E2=80=99t have =
worry about the cache being down etc. 


b.=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 Now the cache being embedded, its using CP=
U and memory from app jvm. It has potential of starving my app of resources=
.


=C2=A0


2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 Have ignite cluster running outside of app JV=
M. So now I run client node in springboot app and connect to main ignite cl=
uster. 


=C2=A0


Few considerations 


=C2=A0


a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 For any reason, if the client node cannot =
connect to main ignite cluster. Do I have to manage the session manually an=
d then push those session manually at later point to the ignite cluster??


b.=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 If I manage session locally I will need to=
 have sticky connection on the load balancer. Which I want to avoid if poss=
ible. 


    

      

    1. 
I am leaning to approach 2, but want to ma=
ke it simple. So if client node cannot create session (override org.apache.=
ignite.cache.websession.WebSessionFilter()) it redirects user to page =
indicating the app is down or to another
 app node in the cluster. 
    



=C2=A0


=C2=A0


Are there any other=
 design approach I can take?


Am I overlooking an=
ything in either approach?



=C2=A0


If you have dealt w=
ith it, please share your thoughts.


=C2=A0


Thanks in advance.



Shri


=C2=A0
This e-mail and its contents (to include attachments) are the property of N= ational Health Systems, Inc., its subsidiaries and affiliates, including bu= t not limited to Rx.com Community Healthcare Network, Inc. and its subsidia= ries, and may contain confidential and proprietary or privileged information. If you are not the intended rec= ipient of this e-mail, you are hereby notified that any unauthorized disclo= sure, copying, or distribution of this e-mail or of its attachments, or the= taking of any unauthorized action based on information contained herein is strictly prohibited. Unauthorized= use of information contained herein may subject you to civil and criminal = prosecution and penalties. If you are not the intended recipient, please im= mediately notify the sender by telephone at 800-433-5719 or return e-mail and permanently delete the original e-mai= l.

--001a1145278c9dd19b0558b0b681--