Hi all,
Since there were concerns as to the maintenance and upkeep of third party
libraries as well as the usage of mDNS in many network set-ups, we have not
gone ahead with the mDNS approach.
All product analytics distributions now ship with a predefined port offset
of 1, and the product
I am not in favor of implementing demoware which will not work in a
production setup. The cumulative maintenance overhead over several years
could be massive. From experience we know what a pain such features can be.
On Wed, Jul 6, 2016 at 11:20 AM, Anjana Fernando wrote:
> Hi
Hi everyone,
We've identified some concerns while doing the implementation. Basically as
Gokul mentioned, he has completed the implementation of this, and when we
are approving a 3'rd party library related to this, Azeez brought up some
concerns on the usefulness of this feature. Basically, the
Hi all,
I have completed implementation of this component, and the relevant PR may
be found at [1].
If I explain the mechanism a bit, an mDNS service is registered for the
Thrift server (i.e. DAS, CEP or product-analytics distributions), provided
that a system flag "receiverDiscoveryEnabled" is
Sure Srinath. However, prior to committing, there are a few concerns with
the approach which I think should be considered: most importantly, how we
should resolve the hostname/IP of the Thrift server. Currently, the Thrift
server is set to listen to all interfaces for incoming connections
Hi Srinath,
As per our offline chat earlier, the initial plan is to locate the Thrift
endpoint through mDNS service discovery, considering the host and port
first.
I have used the JmDNS library pointed by Nirmal to do a PoC on this
scenario, and I've also already incorporated the logic into the
Resending as it hits a filter rule.
Gokul, please give an update on this?
--Srinath
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Hi,
Why not use client auth?
Java SSL X509 specification supports client authentication (keystore on
client, truststore on server). There seems to be a SASL implementation for
Apache Thrift (Java) [1]. Haven't used it personally but worth a shot.
Having to manually specify credentials makes
Hi,
Yes, I was working on this, and the idea is to use TCP multicast to
establish connection settings. The issue however is that in order for the
connection to be fully established, the Thrift auth information is also
needed. Since this obviously shouldn't be multicast, we'll have to get the
user
Hi Srinath,
Yeah, we were doing some work on this, first Malith, and then Gokul. But
due to other priorities we had with the work, we couldn't work on it much.
And we were faced with some issues in how the configuration was done with
it. Where we were thinking of doing some further discussions
No no not using Hazelcast
On Sat, Feb 20, 2016 at 10:07 AM, Srinath Perera wrote:
> Hi Sanjiva,
>
> I think we did though Hazelcast. AFAIK, we have not done it for DAS
> discovery yet.
>
> If we use Hazelcast, it is trivial to do. But that will add Hazelcast to
> all our
Hi Sanjiva,
I think we did though Hazelcast. AFAIK, we have not done it for DAS
discovery yet.
If we use Hazelcast, it is trivial to do. But that will add Hazelcast to
all our products. ( or Maybe we can find and borrow that part of the code).
--Srinath
On Sat, Feb 20, 2016 at 10:00 AM,
On Fri, Feb 19, 2016 at 5:00 PM, Anjana Fernando wrote:
> Hi,
>
> On Fri, Feb 19, 2016 at 4:54 PM, Srinath Perera wrote:
>
>> Kasun, Nuwan
>>
>> All product needs to get DAS server location from one place.
>>
>>
>>1. Do we have a place for that? Otherwise,
Kasun, Nuwan
All product needs to get DAS server location from one place.
1. Do we have a place for that? Otherwise, we need something like
conf/das-client.xml and create a component to read it and use it with API
and ESB when they want to send events to DAS ( Anjana, can ESB analytics
14 matches
Mail list logo