Agreed! we should make sure that we generate a unique name consistently. Let me do that bit of code :-) if you know the problem, and if it is not NP complete, we can solve it ;-)
If we have spend the time that we spend on writing mails to this thread to write that bit of code now it is solved. Thanks, Ruwan On Sun, May 9, 2010 at 2:07 PM, Supun Kamburugamuva <supu...@gmail.com>wrote: > The reason we wanted a name in the first place was to make sure that > endpoints work correctly in a clustered environment. In a > clustered environment same endpoint in different instances require the same > name to work properly because they exchange the state information using the > name as the key. > > So I think generating a unique name across a cluster is very important. If > we cannot generate a unique name across a cluster there is no point in > generating a name at all. > > Thanks, > Supun.. > > > On Fri, May 7, 2010 at 10:20 AM, Ruwan Linton <ruwan.lin...@gmail.com>wrote: > >> I didn't get some time to think through a solution to *consistently* >> generate a unique name for the inlined endpoints, without letting it change >> with every start. If we can do that we do not need to put a warn. If not we >> can consider adding a warn. >> >> Thanks, >> Ruwan >> >> >> On Thu, May 6, 2010 at 4:34 PM, Supun Kamburugamuva <supu...@gmail.com>wrote: >> >>> >>> >>> On Wed, May 5, 2010 at 11:10 PM, Ruwan Linton <ruwan.lin...@gmail.com>wrote: >>> >>>> Agreed! so I was wrong, we can monitor inlined endpoints, but we cannot >>>> manage them via JMX. >>>> >>>> Still, my belief is that we should deal this problem rather than asking >>>> users to always specify a name. >>>> >>>> How about printing a WARN saying we are going to generate a name on >>> behalf of the user and it is better if he can give name, or something like >>> that? >>> >>> Thanks, >>> Supun.. >>> >>> >>>> Thanks, >>>> Ruwan >>>> >>>> >>>> On Wed, May 5, 2010 at 9:09 PM, Supun Kamburugamuva >>>> <supu...@gmail.com>wrote: >>>> >>>>> On Wed, May 5, 2010 at 8:18 PM, Ruwan Linton >>>>> <ruwan.lin...@gmail.com>wrote: >>>>> >>>>>> Folks, >>>>>> >>>>>> Please note that there is noway that we can manage or monitor inlined >>>>>> endpoints. >>>>>> >>>>>> Actually even now we can monitor an inline endpoint using JMX, enable >>>>> statistics and tracing. Only condition is it should have a name. >>>>> >>>>> If it doesn't have a name and if we enable statistics, statistics are >>>>> recorded under the general name AnonymousEndpoint. If we have two of those >>>>> statistics are collected under the same name. That means if I send 1 >>>>> request >>>>> to annon epr1 and 2 requests to annon epr 2, 3 requests will be shown >>>>> under >>>>> the AnonymousEndpoint. >>>>> >>>>> Thanks, >>>>> Supun.. >>>>> >>>>> >>>>>> Even we enforced names for inlined endpoints, there is noway (at least >>>>>> for the moment) that any user can manage/monitor those endpoints, which >>>>>> is >>>>>> simply because there is no means of retrieving inlined endpoints. >>>>>> >>>>>> I am holding my *strong* -1 for enforcing the name for inlined >>>>>> endpoints. >>>>>> >>>>>> To make the developers life easier we are trying to make the life of >>>>>> the user a difficulty. >>>>>> >>>>>> Please give me a list of *tested* advantages that the user get by >>>>>> enforcing a name for the inlined endpoints. >>>>>> >>>>>> Thanks, >>>>>> Ruwan >>>>>> >>>>>> >>>>>> On Wed, May 5, 2010 at 2:43 PM, Hiranya Jayathilaka < >>>>>> hiranya...@gmail.com> wrote: >>>>>> >>>>>>> Hi Supun >>>>>>> >>>>>>> On Wed, May 5, 2010 at 2:28 PM, Supun Kamburugamuva < >>>>>>> supu...@gmail.com> wrote: >>>>>>> >>>>>>>> I think we all agree that having a meaningful name for any endpoint >>>>>>>> (in-line or not) is very important >>>>>>> >>>>>>> >>>>>>> No not really. Most users will be happy with the existing model. >>>>>>> AFAIU most users do not bother with endpoint management stuff. In most >>>>>>> production systems if an endpoint gets suspended then that is due to a >>>>>>> real >>>>>>> serious problem in the deployment. So the answer to that is not to use >>>>>>> JMX >>>>>>> to re-enable the endpoint but to investigate where the problem is. >>>>>>> >>>>>>> >>>>>>>> and is a production best practice. >>>>>>> >>>>>>> >>>>>>> That's correct. >>>>>>> >>>>>>> >>>>>>>> So I'm still not getting why we are not agreeing to force it, >>>>>>>> because the disadvantages to the user are greater than the advantages. >>>>>>> >>>>>>> >>>>>>> Is it? IMO this change will be a major hit on the usability and the >>>>>>> correctness of the model. Totally outweighs the advantages. >>>>>>> >>>>>>> Thanks, >>>>>>> Hiranya >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Supun.. >>>>>>>> >>>>>>>> >>>>>>>> On Wed, May 5, 2010 at 2:23 PM, indika kumara < >>>>>>>> indika.k...@gmail.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> My point exactly :) We should keep anonymous endpoints around since >>>>>>>>>> they are very useful. But the best practice should be to properly >>>>>>>>>> name all >>>>>>>>>> endpoints. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Hiranya >>>>>>>>>> >>>>>>>>> >>>>>>>>> Hiranya ... If you mean that we should avoid the auto generation of >>>>>>>>> the names and keeps anonymous endpoints 'as-is'. That is the behavior >>>>>>>>> in >>>>>>>>> early days including the last release. If so... I would like to add >>>>>>>>> something .. If the correctness of the operation is critical such as >>>>>>>>> clustering and if the user has not specified the name , we should >>>>>>>>> warn or >>>>>>>>> exit. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> Indika >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Software Engineer, WSO2 Inc >>>>>>>> http://wso2.org >>>>>>>> supunk.blogspot.com >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Hiranya Jayathilaka >>>>>>> >>>>>>> Software Engineer; >>>>>>> WSO2 Inc.; http://wso2.org >>>>>>> E-mail: hira...@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: ru...@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: ru...@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: ru...@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: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
