On 08.07.2013 19:51, Mike Sobolewski wrote:
Rafał,
Założenia są następujące:
1. systemowa nazwa servisu w systemie jest SorcerServiceInfo, używana w
exertion signatures;
Używamy też w wersji AFRL Jini ServiceInfo (z jnformacją o produkcie podobną
do serwisów Jini) jesli chcecie mogę to dodać to open source
2. Użytkownik może wrzucić do "entries" (entry w deployment file) co chce
również entry Name (nazwa użytkownika), która nie musi być identyczna (alias) do nazwy
systemowej w SorcerServiceInfo. To może prowadzić do konfliktów systemowych.
3. Service Browser jako nazwę serwisu pokazuje pierwszą instancję Name w
atrybutach proxy, nie z ServiceInfo, bo generic Jini service browser nie wie
nic o SorcerServiceInfo
4. defaultowo entry "name" w w deployment file
a) wstawia nazwę do SorcerServiceInfo (nazwa systemowa servisu)
b) dodateje nazwę jako Name do atrybutów proxy (nazwa użytkownika)
Rozumiem, że:
-użytkownik nie zmienia nazw wbudowanych serwisów sorcera inaczej niż
przez sufiks (zamierzam usunąć wszystkie wystąpienia Name z konfigów)
-jeśli w konfiguracji pojawi się nazwa użytkownika, czyli obiekt typu
Name, nie dodajemy już drugiego takiego atrybutu, tylko SSI.
Czy do nazwy użytkownika powinniśmy automatycznie dodać sufiks?
Kolejne pytanie:
Jak powinno działać wyszukiwanie po nazwie null lub "*"?
Natrafiłem na taką rozbieżność, ze "*" podana jako name w
getService(String,Class) jest zamieniana na nul , natomiast null użyty w
getServiceTemplate jest zamieniany na "undefined".
River nie obsługuje nazwy specjalnej "undefined" i nie zwraca żadnych
wyników, natomiast działa dobrze z null.
Problem objawia się tym, że nie działa load balancing w
CatalogExertDispatcher#execJob - wołany jest getServiceTemplate z
name=null, null zmieniany jest na "undefined" i dostajemy zero jobberów
do rozprowadzenia pod-zadań.
Na razie zmieniłem tak, że pozostawiany jest null i wyszukiwanie działa.
Daj znać czy to jest OK.
--
Pozdrawiam
Rafał Krupiński
