Return-Path: X-Original-To: apmail-ignite-user-archive@minotaur.apache.org Delivered-To: apmail-ignite-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id DE8B817A79 for ; Tue, 2 Jun 2015 11:22:16 +0000 (UTC) Received: (qmail 80205 invoked by uid 500); 2 Jun 2015 11:22:16 -0000 Delivered-To: apmail-ignite-user-archive@ignite.apache.org Received: (qmail 80162 invoked by uid 500); 2 Jun 2015 11:22:16 -0000 Mailing-List: contact user-help@ignite.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@ignite.incubator.apache.org Delivered-To: mailing list user@ignite.incubator.apache.org Received: (qmail 80152 invoked by uid 99); 2 Jun 2015 11:22:16 -0000 Received: from Unknown (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Jun 2015 11:22:16 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 58DBBC0940 for ; Tue, 2 Jun 2015 11:22:16 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 5.174 X-Spam-Level: ***** X-Spam-Status: No, score=5.174 tagged_above=-999 required=6.31 tests=[DKIM_ADSP_CUSTOM_MED=0.001, HTML_MESSAGE=3, NML_ADSP_CUSTOM_MED=1.2, SPF_SOFTFAIL=0.972, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id oklFBlUCS0li for ; Tue, 2 Jun 2015 11:22:06 +0000 (UTC) Received: from mbob.nabble.com (mbob.nabble.com [162.253.133.15]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTP id A05272054B for ; Tue, 2 Jun 2015 11:22:05 +0000 (UTC) Received: from malf.nabble.com (unknown [162.253.133.59]) by mbob.nabble.com (Postfix) with ESMTP id D17CEE05BEC for ; Tue, 2 Jun 2015 04:21:35 -0700 (PDT) Date: Tue, 2 Jun 2015 04:18:21 -0700 (PDT) From: tcostasouza To: user@ignite.incubator.apache.org Message-ID: In-Reply-To: References: <1433201776712-437.post@n6.nabble.com> Subject: Re: Failed to unmarshal service method arguments MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_88888_1092601723.1433243901107" ------=_Part_88888_1092601723.1433243901107 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, Well, it seems that peer deployment does work with peer class loading. The problem I described is with method invocation with arguments that includes classes from the service classpath. Regards On Tue, Jun 2, 2015, 08:04 yakov [via Apache Ignite Users] < ml-node+s70518n440h56@n6.nabble.com> wrote: > Correct link is https://issues.apache.org/jira/browse/IGNITE-975 > > --Yakov > > 2015-06-02 13:03 GMT+03:00 Yakov Zhdanov <[hidden email] > >: > >> Hi! I reproduced the issue and filed a ticket: >> https://issues.apache.org/jira/browse/IGNITE-976 >> >> In the meantime, turn off peer-loading and make all classes available on >> all nodes. This configuration is much better from performance standpoint >> and is recommended in production. >> >> I am also cross-posting this thread to dev list in order to raise a >> question - should services support peer-deployment? My answer is no. >> Service may be implemented in the way that missing classes may be required >> after master node leaves, but service may be configured to stay after >> master leaves. So, even CONTINUOUS deployment mode does not help. >> >> >> >> >> --Yakov >> >> 2015-06-02 2:36 GMT+03:00 tcostasouza <[hidden email] >> >: >> >>> Hello, >>> >>> It seems that, even with peer class loading enabled, Ignite is searching >>> for >>> a Service's method argument classes from it's root classpath. Consider de >>> following example: >>> >>> >>> >>> Now, start 2 Ignite nodes with peer class loading enabled. From one node, >>> deploy and invoke service: >>> >>> >>> Invocation will fail with Ignite complaining that it couldn't find >>> TestServiceImpl class in sun.misc.Launcher$AppClassLoader (full log here >>> < >>> http://apache-ignite-users.70518.x6.nabble.com/file/n437/ignite_exception.log >>> > >>> ) >>> >>> Now, if I change from TestService.execute(TestRequest) to something like >>> TestService.execute(int), then it works as expected. >>> >>> Any clue? >>> >>> Thanks >>> >>> >>> >>> >>> >>> >>> -- >>> View this message in context: >>> http://apache-ignite-users.70518.x6.nabble.com/Failed-to-unmarshal-service-method-arguments-tp437.html >>> Sent from the Apache Ignite Users mailing list archive at Nabble.com. >>> >> >> > If you reply to this email, your message will be added to the discussion > below: > > http://apache-ignite-users.70518.x6.nabble.com/Failed-to-unmarshal-service-method-arguments-tp437p440.html > To unsubscribe from Failed to unmarshal service method arguments, click > here > > . > NAML > > -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Failed-to-unmarshal-service-method-arguments-tp437p441.html Sent from the Apache Ignite Users mailing list archive at Nabble.com. ------=_Part_88888_1092601723.1433243901107 Content-Type: text/html; charset=UTF8 Content-Transfer-Encoding: quoted-printable

Hello,

Well, it seems that peer deployment does work with peer clas= s loading. The problem I described is with method invocation with arguments= that includes classes from the service classpath.

Regards

On Tue, Jun 2, 2015, 08:04=C2=A0yakov [via Apach= e Ignite Users] <[hidden email]= > wrote:
=09

--Yakov
<= /div>

2015-06-02 13:03 GMT+03:00 Yakov Zhdanov <[h= idden email]>:
Hi! I reproduced the issue= and filed a ticket:=C2=A0https://is= sues.apache.org/jira/browse/IGNITE-976

In the meanti= me, turn off peer-loading and make all classes available on all nodes. This= configuration is much better from performance standpoint and is recommende= d in production.

I am also cross-posting this thread= to dev list in order to raise a question - should services support peer-de= ployment? My answer is no. Service may be implemented in the way that missi= ng classes may be required after master node leaves, but service may be con= figured to stay after master leaves. So, even CONTINUOUS deployment mode do= es not help.



--Yakov

2015-06-02 2:36 GMT+03:00 tcostasouza <[hid= den email]>:
Hello,

It seems that, even with peer class loading enabled, Ignite is searching fo= r
a Service's method argument classes from it's root classpath. Consi= der de
following example:



Now, start 2 Ignite nodes with peer class loading enabled. From one node, deploy and invoke service:


Invocation will fail with Ignite complaining that it couldn't find
TestServiceImpl class in sun.misc.Launcher$AppClassLoader (full log=C2=A0 h= ere
<htt= p://apache-ignite-users.70518.x6.nabble.com/file/n437/ignite_exception.log<= /a>>
)

Now, if I change from TestService.execute(TestRequest) to something like TestService.execute(int), then it works as expected.

Any clue?

Thanks






--
View this message in context: http://apache-ignite-user= s.70518.x6.nabble.com/Failed-to-unmarshal-service-method-arguments-tp437.ht= ml
Sent from the Apache Ignite Users mailing list archive at Nabble.com.


=
=09=09
If you reply to this email, your mess= age will be added to the discussion below:
=09=09
=09
=09=09 =09=09To unsubscribe from Failed to unmarshal service method arguments, click here.
=09=09NAML =09
=09 =09 =09
View this message in context: R= e: Failed to unmarshal service method arguments
Sent from the A= pache Ignite Users mailing list archive at Nabble.com.
------=_Part_88888_1092601723.1433243901107--