synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From indika kumara <indika.k...@gmail.com>
Subject Re: Generating Names for Anon. Endpoints
Date Wed, 05 May 2010 08:15:23 GMT
I do not want to prove that I am correct… But as per my experience, a
meaningful name always helped me a lot to track the issue when things go
wrong and to check the correctness of the behavior when did some
modifications on endpoint codes.


On Tue, May 4, 2010 at 11:27 PM, indika kumara <indika.kuma@gmail.com>wrote:

> Ruwan
>
>
>> but JMX management and error notifications like suspensions and so forth
>> cannot be controlled if those endpoints are inlined in, say send mediator.
>> The JMX management and all that are only possible for declared endpoint
>>
>
> I am not sure this ... I have not looked the endpoint code for a long
> time..But as remind , It should just need a name and does not depend on
> in-lined / declared
>
>
>> The only enforcement that we can do to get rid of all that is to disable
>> the ability to have inlined endpoints, but I am strongly -1 on this
>> approach, since it reduces a usability a lot.
>>
>> Also, please note that we do not sacrifice correctness by any means hear,
>> if we do this enforcement, we loose the usability and if we keep this as it
>> is then again what we will loose is the usability, but the usability
>> reduction on the first approach is huge with compared to doing this change.
>>
>> Hence, I am -1 on enforcing a name for inlined endpoints or disabling the
>> ability to have inlined endpoints.
>>
>> Thanks,
>> Ruwan
>>
>>
> I also do not  like to remove in-lined endpoints.... but ....making
> endpoint name mandatory brings advantages than disadvantages to a user even
> he may not be aware at first time the importance of a meaningful name.
>
> Thanks
>
> Indika
>
>
>
>> On Tue, May 4, 2010 at 5:22 PM, indika kumara <indika.kuma@gmail.com>wrote:
>>
>>> I too agree with supun ...
>>>
>>> The usability may depend on the answer for 'Why does a user like in-lined
>>> configurations? '.  That is why I really needed a good answer from real
>>> users...
>>>
>>> The correctness is come first and the most important quality attribute
>>> than other quality attributes.   Irrespective of the criticality of the
>>> operation that depends on the name of the endpoint, the operation should be
>>> worked correctly. At least, if any operation that needs the name of the
>>> endpoint is enabled, then we should validate the uniqueness of the endpoint
>>> name.
>>>
>>> Thanks
>>> Indika
>>>
>>> On Tue, May 4, 2010 at 12:06 PM, Supun Kamburugamuva <supun06@gmail.com>wrote:
>>>
>>>>
>>>>
>>>> On Sun, May 2, 2010 at 5:44 PM, Ruwan Linton <ruwan.linton@gmail.com>wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sun, May 2, 2010 at 11:24 AM, Hiranya Jayathilaka <
>>>>> hiranya911@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, May 1, 2010 at 11:23 PM, Supun Kamburugamuva <
>>>>>> supun06@gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Apr 30, 2010 at 10:08 AM, Hiranya Jayathilaka <
>>>>>>> hiranya911@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi Supun,
>>>>>>>>
>>>>>>>> On Fri, Apr 30, 2010 at 9:02 PM, Supun Kamburugamuva <
>>>>>>>> supun06@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Sorry I'm bit late to the conversation. I think the proper
solution
>>>>>>>>> would be to force the user to have a name for each and
every endpoint.
>>>>>>>>
>>>>>>>>
>>>>>>>> I think we should be a little more flexible here. Most users
will
>>>>>>>> appreciate the ability to define in-line endpoints anonymously.
It's a
>>>>>>>> usability thing.
>>>>>>>>
>>>>>>>>
>>>>>>> Here I'm not suggesting to remove the support
>>>>>>> for anonymous endpoints. My suggestion was to force a name to
every endpoint
>>>>>>> regardless of weather they are defined in-line or separately.
>>>>>>>
>>>>>>
>>>>>> Supun, this is exactly what I think we shouldn't be doing. If we
are
>>>>>> forcing the user to define names for each and every endpoint, then
we are
>>>>>> actually getting rid of the support for anonymous endpoints.
>>>>>>
>>>>>
>>>>> +1
>>>>>
>>>>> We should try our best to keep the simple case as simple. Anonymous
>>>>> endpoints are very usable from the users point of view, and at least
70-80%
>>>>> of the users are not enabling clustering, if we are to enforce a name
for
>>>>> every endpoint regardless whether it is inlined or not, we are making
the
>>>>> simple case hard from the user point of view.
>>>>>
>>>>> My belief is doing the correct thing is important than the usability
at
>>>> least when the usability degradation is minimal. I think that is the exact
>>>> reason why we are trying to make the synapse language schema compliant now.
>>>>
>>>> Also forcing a name for an inline endpoint is not that user un-friendly.
>>>> To define an endpoint user has to do many things. So I think just including
>>>> the name attribute is not a big user un-friendly thing compared to all the
>>>> things user has to do already.
>>>>
>>>> My concerns about name generation are not only with clustering. Lets say
>>>> an anonymous endpoint got suspended or received a time-out error. How can
>>>> the user know which endpoint got suspended or received the error?
>>>>
>>>> Also lets say user wants to do JMX monitoring. How can
>>>> he distinguish the different endpoints?
>>>>
>>>> I think synapse language should always force the production best
>>>> practices and I think having a meaningful name to an endpoint is a
>>>> production best practice that every deployment should do.
>>>>
>>>> Thanks,
>>>> Supun..
>>>>
>>>>
>>>>> Thanks,
>>>>> Ruwan
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Hiranya
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Even now user can do this. But system doesn't enforce this, and
we
>>>>>>> have to generate a name. So my suggestion was to make the name
attribute of
>>>>>>> the endpoint mandatory.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Supun..
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> This is a best practice in a production deployment. The name
helps
>>>>>>>>> to understand endpoint behavior. For example when an
endpoint is suspended
>>>>>>>>> user cannot identify it easily if it doesn't have a name.
>>>>>>>>
>>>>>>>>
>>>>>>>> +1... But it should only be a best practice. If the user
does not
>>>>>>>> want to bother with endpoint management stuff then forcing
him to set names
>>>>>>>> for each and every endpoint is not necessary (Needless to
say, a large
>>>>>>>> config would have dozens and dozens of endpoints - so it's
not an easy job
>>>>>>>> either). Also other than these management capabilities, names
of the in-line
>>>>>>>> endpoints don't have any other usage either. You cannot refer
to them from
>>>>>>>> other sequences etc using the specified name.
>>>>>>>>
>>>>>>>> If the problem is with clustering scenarios, they will work
just
>>>>>>>> fine, since we are generating names for unnamed, in-line
endpoints.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Hiranya
>>>>>>>>
>>>>>>>>
>>>>>>>>> So it is good if we can enforce this at the synapse level.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Supun...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Apr 27, 2010 at 2:44 PM, Ruwan Linton <
>>>>>>>>> ruwan.linton@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> +1
>>>>>>>>>>
>>>>>>>>>> Ruwan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Apr 27, 2010 at 10:55 AM, Hiranya Jayathilaka
<
>>>>>>>>>> hiranya911@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Here's a little progress update. I have realized
that it is
>>>>>>>>>>> difficult to generate descriptive and context
sensitive names for endpoints
>>>>>>>>>>> on the fly. Reason is given an endpoint we cannot
determine it's parent. We
>>>>>>>>>>> can do that for proxy services, but for sequences
it is almost impossible.
>>>>>>>>>>> Therefore we will have to stick to the UUIDs
at least for the moment.
>>>>>>>>>>>
>>>>>>>>>>> However I was able to get the concept of endpoint
anonymity
>>>>>>>>>>> implemented without changing the top level Endpoint
interface. All the
>>>>>>>>>>> endpoint serializers work with the AbstractEndpoint
level, so I added the
>>>>>>>>>>> necessary methods there. If the user hasn't explicitly
specified a name for
>>>>>>>>>>> an endpoint it is considered anonymous. The system
will generate names for
>>>>>>>>>>> such endpoints but they will not be displayed
in the serialization.
>>>>>>>>>>>
>>>>>>>>>>> I have raised SYNAPSE-627 to keep track of this.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Hiranya
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Apr 26, 2010 at 5:34 PM, Ruwan Linton
<
>>>>>>>>>>> ruwan.linton@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> +1
>>>>>>>>>>>>
>>>>>>>>>>>> Ruwan
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Apr 26, 2010 at 5:28 PM, Hiranya
Jayathilaka <
>>>>>>>>>>>> hiranya911@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Apr 26, 2010 at 5:04 PM, Ruwan
Linton <
>>>>>>>>>>>>> ruwan.linton@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hiranya,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Lets introduce an internal flag to
the endpoint so that the
>>>>>>>>>>>>>> builder and the serializer pair sets
and checks respectively to make the
>>>>>>>>>>>>>> generated name transparent from the
users configuration.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To address the issue of having different,
UUID's on different
>>>>>>>>>>>>>> server start sessions, we could compute
the endpoint name by looking at the
>>>>>>>>>>>>>> parent sequence name, for example
like "main_ep_1" and so forth.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> That makes sense. Shall we add following
two methods to the
>>>>>>>>>>>>> Endpoint interface then?
>>>>>>>>>>>>>
>>>>>>>>>>>>> public boolean isAnonymous();
>>>>>>>>>>>>> public void setAnonymous();
>>>>>>>>>>>>>
>>>>>>>>>>>>> Anonymous endpoints will also get a generated
name but that
>>>>>>>>>>>>> will not be shown to the user in the
serialization.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Hiranya
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Ruwan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Apr 26, 2010 at 4:52 PM,
Hiranya Jayathilaka <
>>>>>>>>>>>>>> hiranya911@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Devs,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Currently Synapse generates names
for anonymous endpoints.
>>>>>>>>>>>>>>> For an example take the following
sequence:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <sequence name="foo">
>>>>>>>>>>>>>>>     <send>
>>>>>>>>>>>>>>>        <endpoint>
>>>>>>>>>>>>>>>            <address uri="some
address"/>
>>>>>>>>>>>>>>>        </endpoint>
>>>>>>>>>>>>>>>     </send>
>>>>>>>>>>>>>>> </sequence>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Synapse will generate a UUID
and set that as the name of the
>>>>>>>>>>>>>>> endpoint. This is required since
all endpoints must have names in clustered
>>>>>>>>>>>>>>> deployments. However generating
names causes the serialization to be
>>>>>>>>>>>>>>> different from the original input
XML. As a result we currently have a bunch
>>>>>>>>>>>>>>> of test failures in the trunk.
Any idea how to resolve this problem?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Hiranya Jayathilaka
>>>>>>>>>>>>>>> Software Engineer;
>>>>>>>>>>>>>>> WSO2 Inc.;  http://wso2.org
>>>>>>>>>>>>>>> E-mail: hiranya@wso2.com;  Mobile:
+94 77 633 3491
>>>>>>>>>>>>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Ruwan Linton
>>>>>>>>>>>>>> Technical Lead & Product Manager;
WSO2 ESB;
>>>>>>>>>>>>>> http://wso2.org/esb
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> WSO2 Inc.; http://wso2.org
>>>>>>>>>>>>>>  email: ruwan@wso2.com; cell: +94
77 341 3097
>>>>>>>>>>>>>> blog: http://ruwansblog.blogspot.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Hiranya Jayathilaka
>>>>>>>>>>>>> Software Engineer;
>>>>>>>>>>>>> WSO2 Inc.;  http://wso2.org
>>>>>>>>>>>>> E-mail: hiranya@wso2.com;  Mobile: +94
77 633 3491
>>>>>>>>>>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Ruwan Linton
>>>>>>>>>>>> Technical Lead & Product Manager; WSO2
ESB; http://wso2.org/esb
>>>>>>>>>>>> WSO2 Inc.; http://wso2.org
>>>>>>>>>>>> email: ruwan@wso2.com; cell: +94 77 341 3097
>>>>>>>>>>>> blog: http://ruwansblog.blogspot.com
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Hiranya Jayathilaka
>>>>>>>>>>> Software Engineer;
>>>>>>>>>>> WSO2 Inc.;  http://wso2.org
>>>>>>>>>>> E-mail: hiranya@wso2.com;  Mobile: +94 77 633
3491
>>>>>>>>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Ruwan Linton
>>>>>>>>>> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
>>>>>>>>>> WSO2 Inc.; http://wso2.org
>>>>>>>>>> email: ruwan@wso2.com; cell: +94 77 341 3097
>>>>>>>>>> blog: http://ruwansblog.blogspot.com
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Software Engineer, WSO2 Inc
>>>>>>>>> http://wso2.org
>>>>>>>>> supunk.blogspot.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Hiranya Jayathilaka
>>>>>>>> Software Engineer;
>>>>>>>> WSO2 Inc.;  http://wso2.org
>>>>>>>> E-mail: hiranya@wso2.com;  Mobile: +94 77 633 3491
>>>>>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Software Engineer, WSO2 Inc
>>>>>>> http://wso2.org
>>>>>>> supunk.blogspot.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Hiranya Jayathilaka
>>>>>> Software Engineer;
>>>>>> WSO2 Inc.;  http://wso2.org
>>>>>> E-mail: hiranya@wso2.com;  Mobile: +94 77 633 3491
>>>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Ruwan Linton
>>>>> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
>>>>> WSO2 Inc.; http://wso2.org
>>>>> email: ruwan@wso2.com; cell: +94 77 341 3097
>>>>> blog: http://ruwansblog.blogspot.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Software Engineer, WSO2 Inc
>>>> http://wso2.org
>>>> supunk.blogspot.com
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Ruwan Linton
>> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
>> WSO2 Inc.; http://wso2.org
>> email: ruwan@wso2.com; cell: +94 77 341 3097
>> blog: http://ruwansblog.blogspot.com
>>
>
>

Mime
View raw message