Mailing-List: contact celix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: celix-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of a.broekhuis@gmail.com
 designates 209.85.128.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <11a25c20b9e79462c12693cafc016bfe@imap.sundevil.de>
References: <5213C63A.1050002@gmail.com>
	<E825BCB2-EAFD-4E97-88C0-B1BB1085506A@luminis.nl>
	<52150460.7070606@gmail.com>
	<CA+T-u8e2tvMgKdj9FjQ6h5ACQFmT11k8RpvKJ-Ci64HoW9fYEw@mail.gmail.com>
	<52356979.1040002@sundevil.de>
	<CA+T-u8fOd9TbY5W2h4PYxrLJzo1-mM09c3=CbOMEQ8TLio-Rqw@mail.gmail.com>
	<03fa0772516eaaab4c1fcf59f52f00e9@imap.sundevil.de>
	<CA+T-u8cs9Bioac7NwDFf3xuggRfSgBnKORrwwLJB34y_LE6QWQ@mail.gmail.com>
	<dbdb0588141d589373b66404ce2b8ecd@imap.sundevil.de>
	<CA+T-u8ccYmz15uZd8TP3LAZGW74MCTbrUs=+Bqay=jR6pZQ=eA@mail.gmail.com>
	<5238198D.8050209@sundevil.de>
	<CA+T-u8e4s4UuDbXk=wDZkhZ7+OSo7Z22E8ROQk5hSyD9DvdxVw@mail.gmail.com>
	<CA+T-u8eecxMJvwwuP=LZU9TXEkv09C3EZXtUFnOWCOfuGBs4nA@mail.gmail.com>
	<4f9dbca6c64a7583e34c4be4cab8eadc@imap.sundevil.de>
	<CA+T-u8fDDmRPwJjxbiqb8cLVbtq4cZxD5ar1FWGaBbejgPdq+w@mail.gmail.com>
	<52454D60.9030906@sundevil.de>
	<CA+T-u8ei8MpVZp8HtZy6E66+Gfcn5urm+gYUFRHB21XZYsmZcg@mail.gmail.com>
	<bc45451b45d3571b60b11abb2131a151@imap.sundevil.de>
	<CA+T-u8cnsBAxO6q_Ud8BgE9h8qjJevrrQK1kZNfzNWkv4irKOQ@mail.gmail.com>
	<617379229e8f0bcdc85d3ed8fe429f1d@imap.sundevil.de>
	<11a25c20b9e79462c12693cafc016bfe@imap.sundevil.de>
Date: Thu, 5 Dec 2013 17:17:57 +0100
Message-ID: 
 <CA+T-u8dD40CT7O5p28OzN3g5WMRMVTTOGEXq_1AF=CSf24aEvQ@mail.gmail.com>
Subject: Re: Remote service using shared mem
From: Alexander Broekhuis <a.broekhuis@gmail.com>
To: celix-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=047d7b6dc0bc70257804eccbdf7f

--047d7b6dc0bc70257804eccbdf7f
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Bjoern,

I'm now trying to apply the patch and have some new issues, I've added some
remarks in between:

* It is created against an older revision, some small changes that easily
can be fixed.
  For a final patch I'd like this to be solved, but isn't a big issue.
* It now uses "semtimedop", which is a GLibC function (and not posix) so
now it doesn't work on OSX.
  While I think we should work towards a broader support with these kind of
things, I can live with the first version being Linux (GLibC) only. But
this does mean I cannot test it at this moment.. So someone should
definitely still do this (Pepijn?)
* Calculator Endpoint/Proxy uses the older format for the JSON data (which
is incompatible with the Amdatu RSA).
  This is a small change in the encoding/decoding, but isn't a big issue.
* The SHM RSA uses setHandler/setCallback instead of setEndpointProperties.
The existing HTTP RSA doesn't use these yet.
  At this moment this breaks the Calculator example when used with the HTTP
RSA. Probably not that difficult to port back to the HTTP RSA. I prefer the
newer method, so definitely in favour of applying those changes to the HTTP
RSA as well.

Some other remarks/updates not yet mentioned on this list:
Yesterday we already talked about how to donate this code. Since this code
introduces new bundles it makes the most sense to handle this using a Code
Grant and IP Clearance.
We already discussed that Pepijn is willing to do the paper work, so
hopefully it al doesn't take that much time.

So to summarize (in order):
1) We need a working set of bundles (at least tested on Linux, preferably
on OSX as well). Existing code should still work as well.
2) After that a code grant with Issue number and MD5 sum needs to be filled
in and filed.
3) Finally the IP Clearance should be handled.

I have some time to do some work, so I can help out a bit. For now I'll
work on getting the setHandler/setCallback method in the HTTP RSA as well,
if that is in place, ideally you shouldn't need to update those for the SHM
RSA.

Anything I forgot or overlooking?


2013/12/4 Bj=F6rn Petri <bjoern.petri@sundevil.de>

>
>
> I updated the functionality of the discovery component to ensure that all
> threads perform its update routine, when a service was added/stopped or t=
he
> discovery bundle is stopped.
>
> I would be happy if you find the time to give it a short check.
>
> Regards,
>   Bjoern
>
>
>
>
>
> Am 2013-10-03 14:07, schrieb Bj=F6rn Petri:
>
>  Hi Alexander,
>>
>> introducing the lock in the discovery_stop function was done with
>> purpose. The unlocking and locking should enable all
>> discovery-polling-threads to update their local list of services and
>> in the case of the stopping discovery bundle it should allow the
>> thread to leave it's loop (the loop control variable should be set to
>> false before performing the unlock and lock). So, it should actually
>> not wait on the join - I'll take a look at the code and check what is
>> going on there.
>>
>> Regards,
>>   Bj=F6rn
>>
>>
>>
>>
>> Am 2013-10-03 11:59, schrieb Alexander Broekhuis:
>>
>>> Hi Bjoern,
>>>
>>> I have some problems with the discovery now. If I try to stop the
>>> discovery
>>> bundle, it tries to join the discovery thread, but somehow the lock isn=
't
>>> released and the thread doesn't exit.
>>>
>>> Looking in the code, the discovery_stop now has an unlock directly
>>> followed
>>> by a lock. This seems to be the problem. Did a small error sneak in? Or
>>> is
>>> there some reason for the unlock/lock?
>>>
>>> I'll do some more testing later on this week, so I'll get back to you :=
)
>>>
>>>
>>> 2013/10/2 Bj=F6rn Petri <bjoern.petri@sundevil.de>
>>>
>>>
>>>> Alexander,
>>>>
>>>> I updated the rs shared memory implementation to
>>>>
>>>> (1) use System-V shared memory routines instead of ones from APR,
>>>> (2) make use of your install_bundles macro,
>>>> (3) perform some necessary cleanup when the exported service is stoppe=
d
>>>> (This is also missing in the "standard"-rsa implementation). See
>>>> remoteServiceAdmin_**removeExportedService function for details,
>>>> (4) get rid of the linking of the example_proxy against the rsa_shm,
>>>> (5) and fixed some minor bugs.
>>>>
>>>> looking forward to your feedback,
>>>>   Bjoern
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Am 2013-09-27 16:11, schrieb Alexander Broekhuis:
>>>>
>>>>  2013/9/27 Bj=F6rn Petri <bjoern.petri@sundevil.de>
>>>>
>>>>>
>>>>>  On 09/18/2013 06:29 PM, Alexander Broekhuis wrote:
>>>>>
>>>>>>
>>>>>>  I checked it, and there are some small leftovers in the code. The
>>>>>> proxy
>>>>>>
>>>>>>> still includes the rsa and also links with the library.
>>>>>>>
>>>>>>>
>>>>>>>  How do you want to get rid of this dependency? The proxy needs to
>>>>>> include
>>>>>> definition of the remote_proxy_service as well as the rsa does. Do I
>>>>>> miss
>>>>>> something?
>>>>>>
>>>>>>
>>>>>>  Since the proxy now uses the function pointer and only the service
>>>>> struct
>>>>> of the RSA it only needs the header files (as far as I can tell). Als=
o,
>>>>> with the concept of bundles, and Celix not supporting code-sharing at
>>>>> this
>>>>> point, bundles (actually the library in it) should never link to a
>>>>> library
>>>>> of any other bundle.
>>>>> Libraries are loaded locally, so the symbols aren't shared with
>>>>> others. So
>>>>> this means that if you link with another bundle, at runtime there wil=
l
>>>>> be
>>>>> unresolved references. Hence the need for services (structs with
>>>>> function
>>>>> pointers) etc.
>>>>>
>>>>>
>>>>
>>>>
>


--=20
Met vriendelijke groet,

Alexander Broekhuis

--047d7b6dc0bc70257804eccbdf7f--