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.
Th
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 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, Su
On Wed, May 5, 2010 at 11:10 PM, Ruwan Linton 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 w
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.
Thanks,
Ruwan
On Wed, May 5, 2010 at 9:09 PM, Supun Kamburugamuva wrote:
> On Wed, May 5, 2010 at
On Wed, May 5, 2010 at 8:18 PM, Ruwan Linton 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 doe
Folks,
Please note that there is noway that we can manage or monitor inlined
endpoints.
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 endpoint
Hi Supun
On Wed, May 5, 2010 at 2:28 PM, Supun Kamburugamuva 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
On Wed, May 5, 2010 at 2:23 PM, indika kumara 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
I think we all agree that having a meaningful name for any endpoint (in-line
or not) is very important and is a production best practice. 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.
Thanks,
Supun..
On Wed, Ma
> 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
On Wed, May 5, 2010 at 2:02 PM, indika kumara wrote:
> 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 co
I also believe that we should invent a mechanism that allows user avoiding
the redundancy in the endpoint configurations… in other words , a proper
reuse… May be based on a policy-based approach
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.
At first time in early days in synapse, I really preferre
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 wrote:
>
Hi Indika,
On Wed, May 5, 2010 at 12:10 PM, indika kumara wrote:
> Have u tested multiple instances ... ? as names are random , a name is
> different for same endpoint in each synapse instance .. States are
> replicated based name + some ID for an endpoint...
>
I haven't tested this thoroughly
Have u tested multiple instances ... ? as names are random , a name is
different for same endpoint in each synapse instance .. States are
replicated based name + some ID for an endpoint...
On Wed, May 5, 2010 at 12:32 PM, Hiranya Jayathilaka
wrote:
>
>
> On Wed, May 5, 2010 at 11:48 AM, indika
On Wed, May 5, 2010 at 11:48 AM, indika kumara wrote:
> ... So with randomly generated names , clustering should not work
>
No it works. At least I haven't encountered any issues thus far.
Thanks,
Hiranya
>
> On Wed, May 5, 2010 at 12:17 PM, indika kumara wrote:
>
>>
>>> Indika, we generate U
... So with randomly generated names , clustering should not work
On Wed, May 5, 2010 at 12:17 PM, indika kumara wrote:
>
>> Indika, we generate UUIDs for endpoint names. So it is unique :)
>>
>
> OK ... But for clustering , 100% endpoint configurations should be equal in
> each server instance
>
>
> Indika, we generate UUIDs for endpoint names. So it is unique :)
>
OK ... But for clustering , 100% endpoint configurations should be equal in
each server instance ... But how can do with randomlely generated names
? ...
Indika
On Tue, May 4, 2010 at 9:55 PM, indika kumara wrote:
> What makes you think the current approach for endpoints is 'incorrect'? If
>> it is not correct then that indeed is a problem we should get fixed
>>
>
> Hiranja
>
> As currently, we generate a random one (so unique), therefore the internal
>
On Tue, May 4, 2010 at 10:57 PM, indika kumara
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
>
> However, the clustering is not. It is an internal operation.
>
>
Sorry, I was wrong by.. The clustering is needed careful effort from
user. Unique names are mandatory and same names should be in all synapse
instances of the cluster. This cannot be done with the random name
generation as user
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
my thoughts is inline
On Tue, May 4, 2010 at 6:23 PM, Hiranya Jayathilaka wrote:
> Sending as a separate mail since my responses to the previous thread are
> getting bounced off :(
>
> Hi Indika,
>
> On Mon, May 3, 2010 at 8:10 PM, indika kumara
> wrote:
>
>> As the synapse configuration is the
>
> What makes you think the current approach for endpoints is 'incorrect'? If
> it is not correct then that indeed is a problem we should get fixed
>
Hiranja
As currently, we generate a random one (so unique), therefore the internal
operation is correct as far as users do not specify a name. How
s/correction/correctness
Ruwan
On Tue, May 4, 2010 at 9:11 PM, Ruwan Linton wrote:
> Folks,
>
> I completely agree that the correction is the highest priority.
>
> but JMX management and error notifications like suspensions and so forth
> cannot be controlled if those endpoints are inlined in,
Folks,
I completely agree that the correction is the highest priority.
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.
The
Hi Indika
On Tue, May 4, 2010 at 5:22 PM, indika kumara 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
Sending as a separate mail since my responses to the previous thread are
getting bounced off :(
Hi Indika,
On Mon, May 3, 2010 at 8:10 PM, indika kumara wrote:
> As the synapse configuration is the API for end-users to program their
> solutions using synapse, the usability for the end user is i
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. Irrespectiv
On Sun, May 2, 2010 at 5:44 PM, Ruwan Linton wrote:
>
>
> On Sun, May 2, 2010 at 11:24 AM, Hiranya Jayathilaka > wrote:
>
>>
>>
>> On Sat, May 1, 2010 at 11:23 PM, Supun Kamburugamuva
>> wrote:
>>
>>>
>>>
>>> On Fri, Apr 30, 2010 at 10:08 AM, Hiranya Jayathilaka <
>>> hiranya...@gmail.com> wrot
As the synapse configuration is the API for end-users to program their
solutions using synapse, the usability for the end user is important.
Why does a user like in-lined configurations?
Is it really difficult to give a meaningful yet unique name? Or ..because
there is no reuse for an endpoint
On Sun, May 2, 2010 at 11:24 AM, Hiranya Jayathilaka
wrote:
>
>
> On Sat, May 1, 2010 at 11:23 PM, Supun Kamburugamuva wrote:
>
>>
>>
>> On Fri, Apr 30, 2010 at 10:08 AM, Hiranya Jayathilaka <
>> hiranya...@gmail.com> wrote:
>>
>>> Hi Supun,
>>>
>>> On Fri, Apr 30, 2010 at 9:02 PM, Supun Kamburuga
On Sat, May 1, 2010 at 11:23 PM, Supun Kamburugamuva wrote:
>
>
> On Fri, Apr 30, 2010 at 10:08 AM, Hiranya Jayathilaka <
> hiranya...@gmail.com> wrote:
>
>> Hi Supun,
>>
>> On Fri, Apr 30, 2010 at 9:02 PM, Supun Kamburugamuva
>> wrote:
>>
>>> Sorry I'm bit late to the conversation. I think the p
On Sat, May 1, 2010 at 11:23 PM, Supun Kamburugamuva wrote:
>
>
> On Fri, Apr 30, 2010 at 10:08 AM, Hiranya Jayathilaka <
> hiranya...@gmail.com> wrote:
>
>> Hi Supun,
>>
>> On Fri, Apr 30, 2010 at 9:02 PM, Supun Kamburugamuva
>> wrote:
>>
>>> Sorry I'm bit late to the conversation. I think the p
On Fri, Apr 30, 2010 at 10:08 AM, Hiranya Jayathilaka
wrote:
> Hi Supun,
>
> On Fri, Apr 30, 2010 at 9:02 PM, Supun Kamburugamuva 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
Hi Supun,
On Fri, Apr 30, 2010 at 9:02 PM, Supun Kamburugamuva 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 a
Supun why users want to specify an endpoint in-lined
does user not like to specify a name ?
or
does user not like to define an endpoint and use it by referring because the defined endpoint is only used and not reused
by many ... therefore , is a little bit redundant
... ?
If the cas
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. 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
identi
+1
Ruwan
On Tue, Apr 27, 2010 at 10:55 AM, Hiranya Jayathilaka
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 t
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
+1
Ruwan
On Mon, Apr 26, 2010 at 5:28 PM, Hiranya Jayathilaka
wrote:
>
>
> On Mon, Apr 26, 2010 at 5:04 PM, Ruwan Linton 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 na
On Mon, Apr 26, 2010 at 5:04 PM, Ruwan Linton 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 d
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 comp
Devs,
Currently Synapse generates names for anonymous endpoints. For an example
take the following 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 deployment
46 matches
Mail list logo
