Re: [Architecture] Session Affinity Alternatives

My suggestion is to recommend option 1. But make option 2 available for people who need to use it. If session affinity is not available - it will discourage people from writing applications that have to maintain state (and if they have to option 2 is available albeit a little harder). Also for opti

Re: [Architecture] Have we looked at supporting "Kiosk" mode as part of the proposed "COPE" implementation?

Hi all, This can be easily done (kiosk mode) in devices which have android 5 or higher. This was introduced in Android 5.0 as the *Screen Pining* feature. Please refer below description of the feature which is available in [1]. Android 5.0 introduces a new screen pinning API that lets you tempor

Re: [Architecture] The new disruptor based Netty transport is not working well for MSF4J

If we have issues with disruptor, those issues are equally affecting GW or GW based servers for most of the real use cases. So fixing that in the proper way and continue to use the same architecture for both GW and MSF4J looks ideal to me. On Thu, Mar 10, 2016 at 10:26 AM, Afkham Azeez wrote: >

Re: [Architecture] Session Affinity Alternatives

I forgot to add earlier our design decision about using Redis to store sessions; the Kubernetes scheduler may decide to kill & container & start up different instance if its health checks detects problems. So in such a case, if we had used affinity, the clients connected to that instance which was

Re: [Architecture] [PET] Office 365 Connector

Hi Malaka, Yes, I will include the following methods for the initial version of outlook connector. Messages - Get a message by ID. - Get a message collection - Send a new message - Reply to sender - Reply to all - Forward a message directly - Delete a message - Move a message - Copy a messag

Re: [Architecture] The new disruptor based Netty transport is not working well for MSF4J

No from day 1, we have decided that GW & MSF4J will use the same Netty transport component so that the config file will be the same as well as improvements made to that transport will be automatically available for both products. So now at least for MSF4J, we have issues in using the Netty transpor

Re: [Architecture] Session Affinity Alternatives

Petstore is #2. We use the Redis service to store the session. For an HA deployment such a model is required, but yes, for the simplest case, we can have local sessions and then use session affinity capabilities of the LB. On Thu, Mar 10, 2016 at 10:17 AM, Sanjiva Weerawarana wrote: > Manu, #1 i

Re: [Architecture] The new disruptor based Netty transport is not working well for MSF4J

When we discuss last week about Carbon transports for MSF4J the main rational we identified was moving to Carbon transport will decouple transport threads from worker threads through Disruptor and provide lot of flexibility and manageability. If disruptor can't give better performance we should ski

Re: [Architecture] Session Affinity Alternatives

Manu, #1 is not a no-session story. What Azeez has done for the petstore is a model where session state is in a DB. Session as a service is the same thing ... basically a data service in front of a DB. So really the basic question is can you do without a session? My answer is no, not practical. I

Re: [Architecture] [PET] Office 365 Connector

Hi Thulashika, +1 for outlook connector. However we can limit the methods for the initial version. eg:- Messages - Get a message by ID. - Get a message collection - Send a new message - Reply to sender - Reply to all - Forward a message directly - Delete a message Attachments - Get

Re: [Architecture] The new disruptor based Netty transport is not working well for MSF4J

We need to do this fast because this task has taken close to 3 weeks now. On Thu, Mar 10, 2016 at 9:29 AM, Kasun Indrasiri wrote: > Yes, we can make the disruptor optional. Also, we should try using the > native worker pool for Event Handler[1], so that the Disruptor itself runs > the event hand

Re: [Architecture] The new disruptor based Netty transport is not working well for MSF4J

Yes, we can make the disruptor optional. Also, we should try using the native worker pool for Event Handler[1], so that the Disruptor itself runs the event handler on a worker pool. We'll implement both approaches and do a comparison. [1] https://lmax-exchange.github.io/disruptor/docs/com/lmax/dis

[Architecture] The new disruptor based Netty transport is not working well for MSF4J

After upgrading to the new transport, we are seeing a significant drop in performance for any service that take some time to execute. We have tried with the configuration used for the gateway which gave the best figures on the same hardware. We have also noted that using a separate dedicated execut

[Architecture] [App Cloud] GitHub Integration

hi All, I am working on GitHub integration with App Cloud. Please find the user stories below. User Stories 1. Public git repo (Anonymous users will have read access) Prerequisite: - It requires to create a webhook under the GitHub repo to invoke the endpoint provided by App

Re: [Architecture] [IS] Proposed Architectural Change for Authentication Framework

Sorry, there seems to be a problem with the image. Adding it below. [image: Inline image 1] On Thu, Mar 10, 2016 at 1:16 AM, Pulasthi Mahawithana wrote: > Hi, > > Identity Server’s Authentication framework’s current implementation has > following limitations. > > >1. When writing custom com

[Architecture] [DEV] WSO2 App Manager 1.2.0 Milestone 2 Released

Hi All, WSO2 App Manager team pleased to announce the WSO2 APP Manager 1.2.0 - Milestone 2 release. It contains following new features, improvements and bug fixes. You can download this distribution from below link. *http://builder1.us1.wso2.org/~appm/release-1.2.0/M2/wso2appm-1.2.0-M2.zip

[Architecture] [IS] Proposed Architectural Change for Authentication Framework

Hi, Identity Server’s Authentication framework’s current implementation has following limitations. 1. When writing custom components to the framework, even to do a minor modification, we have to write a considerable amount of code because the interfaces are too abstract. Also extending

Re: [Architecture] Session Affinity Alternatives

On Wed, Mar 9, 2016 at 8:01 PM, Manuranga Perera wrote: > Options > 1) No session. Everything is in DB or Window.localStorage. Authentication > via a token validation endpoint. (We keep the token in a front end cookie) > 2) Session as a service > 3) The session is local, works with session affini

Re: [Architecture] Session Affinity Alternatives

Options 1) No session. Everything is in DB or Window.localStorage. Authentication via a token validation endpoint. (We keep the token in a front end cookie) 2) Session as a service 3) The session is local, works with session affinity 4) The session is distributed My personal order of preference -

Re: [Architecture] [AS 6.0.0] HTTP Monitoring dashboard - Why are we parsing the User-Agent header in the event builder?

Yes, we need to minimize such overhead at data publishing side and do these type of processing during summarization as Janaka suggested. On Wed, Mar 9, 2016 at 10:58 AM, Manoj Kumara wrote: > I too think its a valid concern. +1 to publish the complete header as it > is. > > @Lochana, > Please no

Re: [Architecture] Session Affinity Alternatives

Not practical Azeez - you're massively complicating the deployment and second its far less performant than replication. Earlier we did global replication which we really shouldn't do. I'm not suggesting replication .. I'm saying we support non-HA sessions by default but make that part pluggable so

Re: [Architecture] Session Affinity Alternatives

What if we follow an approach of persisting the session to a datastore, like we've done in the petstore sample, that way you don't need to worry about affinity or the node having the session failing. In memory session replication is costly & leads to a whole lot of other issues, like the ones we've

Re: [Architecture] Session Affinity Alternatives

Manu's question is in the context of the reusable UI framework stuff we're working on. Fundamentally, is it necessary to have sessions to write a UI? Can we use HATEOS for some stuff, browser local storage for some stuff etc. and not have sessions at all?? I feel we need sessions as a lot of simp

Re: [Architecture] Session Affinity Alternatives

With such a model, you don't have to worry about things like session replication in order to achieve HA. On Wed, Mar 9, 2016 at 3:32 PM, Manuranga Perera wrote: > Should we aim to do the same in the UIs we ship, such as products ES? > There will be some extra effort. > > On Wed, Mar 9, 2016 at 2

Re: [Architecture] ESB Connector for Asana

Thank you Malaka, Sure we also expect that. On Wed, Mar 9, 2016 at 3:38 PM, Malaka Silva wrote: > Hi Nirthika, > > Good progress. We are also planning to arrange a meetup at Jaffna office > in April. Feel free to come. > > On Wed, Mar 9, 2016 at 1:35 PM, Nirthika Rajendran < > nirthika.rajend..

Re: [Architecture] [PET] Office 365 Connector

Hi Malaka, Then we can implement multiple connectors for each APIs. So First I will start to implement the connector for Mail API with following methods. Mail API :The Mail API lets you read, create, and send messages and attachments, view and respond to event messages, and manage folders that a

Re: [Architecture] ESB Connector for Asana

Hi Nirthika, Good progress. We are also planning to arrange a meetup at Jaffna office in April. Feel free to come. On Wed, Mar 9, 2016 at 1:35 PM, Nirthika Rajendran < nirthika.rajend...@gmail.com> wrote: > Hi Malaka, > > Every members in my team nearly take 10 methods and do the documentation >

Re: [Architecture] Session Affinity Alternatives

Should we aim to do the same in the UIs we ship, such as products ES? There will be some extra effort. On Wed, Mar 9, 2016 at 2:12 PM, Afkham Azeez wrote: > In the petstore sample, the sessions of the frontend apps are stored in > Redis. > > On Wed, Mar 9, 2016 at 1:57 PM, Imesh Gunaratne wrote

Re: [Architecture] [PET] Office 365 Connector

Hi Thulasika, Are we planning to do one connector or multiple connectors? IMO we should have separate connector for each domain. On Tue, Mar 8, 2016 at 8:53 PM, Thulasika Vijayanathan wrote: > Hi All, > > I have planned to develop office 365 connector using REST API[1] with the > following Met

Re: [Architecture] [Greg]Optimal VM heap size for Greg 5.2 performance testing

Hi Isuru, Sorry for delay in reply, On Tue, Mar 8, 2016 at 2:06 PM, Isuru Perera wrote: > Hi Kasun, > > As you mentioned, the 2GB heap gives a better throughput than 1GB heap and > therefore it's good to do performance tests with 2GB heap. > > Since there is about 96% throughput, we may not nee

Re: [Architecture] Session Affinity Alternatives

In the petstore sample, the sessions of the frontend apps are stored in Redis. On Wed, Mar 9, 2016 at 1:57 PM, Imesh Gunaratne wrote: > Hi Manuranga, > > Yes, what you are saying it true! We should only use session aware load > balancing for existing applications which has session management fea

Re: [Architecture] Session Affinity Alternatives

Hi Manuranga, Yes, what you are saying it true! We should only use session aware load balancing for existing applications which has session management features built into them. Ideally when implementing new applications those should be designed in a way to store their sessions outside the applica

Re: [Architecture] ESB Connector for Asana

Hi Malaka, Every members in my team nearly take 10 methods and do the documentation and integration test for their part also. Now we all finished about 40 methods and user documentation. This month we have final semi examination, So we plan to continue the remaining part after the exam. Thank y