Thread: [Jolie-devel] OneWay messages
A service-oriented programming language.
Brought to you by:
fmontesi
Menu
▾
▴
jolie-devel
|
From: Matthias D. W. <mwa...@ya...> - 2013-11-21 10:04:22
|
Hi developers, I got another question: in http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment we have a simple client-server example: > |main| > |{| > |||twice( number )( response ) {| > |||response = number * ||2| > |||}| > |}| But when I change it to be one-way I run into trouble: > interface TwiceInterface { > OneWay: twice( int ) > } and > main > { > twice( number ) { > result = number * 2; > println@Console( result )(); > } > } does not work. Why? Do I need something like this? > main > { > [ twice( number ) ] { > result = number * 2; > println@Console( result )(); > } > } Cheers, Matthias |
|
From: Fabrizio M. <fam...@gm...> - 2013-11-21 10:22:42
|
Hi Matthias,
this:
> twice( number ) {
> result = number * 2;
> println@Console( result )();
> }
is not a construct in the language. Request-Response operations
support the { block } construct because it is useful to specify
something to happen *in-between* the request and the response. For
one-ways this is not necessary because they just receive something.
Hence you can just use the semicolon operator for expressing a
sequence and obtain what you want:
twice( number );
result = number * 2;
println@Console( result )()
Cheers,
Fabrizio.
On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer
<mwa...@ya...> wrote:
> Hi developers,
>
> I got another question: in
> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment
> we have a simple client-server example:
>> |main|
>> |{|
>> |||twice( number )( response ) {|
>> |||response = number * ||2|
>> |||}|
>> |}|
>
> But when I change it to be one-way I run into trouble:
>> interface TwiceInterface {
>> OneWay: twice( int )
>> }
> and
>> main
>> {
>> twice( number ) {
>> result = number * 2;
>> println@Console( result )();
>> }
>> }
> does not work. Why?
>
> Do I need something like this?
>> main
>> {
>> [ twice( number ) ] {
>> result = number * 2;
>> println@Console( result )();
>> }
>> }
>
> Cheers,
> Matthias
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> Jolie-devel mailing list
> Jol...@li...
> https://lists.sourceforge.net/lists/listinfo/jolie-devel
|
|
From: Matthias D. W. <mwa...@ya...> - 2013-11-21 10:53:36
|
Hi Fabrizio,
this works well, but on the client side
> main
> {
> twice@TwiceService( 5 )
> }
I get a Java EOF exception. I imagine that this could be a coordination
issue?
> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning
> WARNING: [client.ol] java.io.EOFException
> at java.io.DataInputStream.readFully(DataInputStream.java:197)
> at java.io.DataInputStream.readLong(DataInputStream.java:416)
> at jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252)
> at jolie.net.SodepProtocol.recv(SodepProtocol.java:305)
> at jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92)
> at jolie.net.CommChannel.recv(CommChannel.java:198)
> at
> jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
Cheers,
Matthias
Fabrizio Montesi schrieb:
> Hi Matthias,
> this:
>> twice( number ) {
>> result = number * 2;
>> println@Console( result )();
>> }
> is not a construct in the language. Request-Response operations
> support the { block } construct because it is useful to specify
> something to happen *in-between* the request and the response. For
> one-ways this is not necessary because they just receive something.
> Hence you can just use the semicolon operator for expressing a
> sequence and obtain what you want:
>
> twice( number );
> result = number * 2;
> println@Console( result )()
>
>
> Cheers,
> Fabrizio.
>
>
> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer
> <mwa...@ya...> wrote:
>> Hi developers,
>>
>> I got another question: in
>> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment
>> we have a simple client-server example:
>>> |main|
>>> |{|
>>> |||twice( number )( response ) {|
>>> |||response = number * ||2|
>>> |||}|
>>> |}|
>> But when I change it to be one-way I run into trouble:
>>> interface TwiceInterface {
>>> OneWay: twice( int )
>>> }
>> and
>>> main
>>> {
>>> twice( number ) {
>>> result = number * 2;
>>> println@Console( result )();
>>> }
>>> }
>> does not work. Why?
>>
>> Do I need something like this?
>>> main
>>> {
>>> [ twice( number ) ] {
>>> result = number * 2;
>>> println@Console( result )();
>>> }
>>> }
>> Cheers,
>> Matthias
>>
>> ------------------------------------------------------------------------------
>> Shape the Mobile Experience: Free Subscription
>> Software experts and developers: Be at the forefront of tech innovation.
>> Intel(R) Software Adrenaline delivers strategic insight and game-changing
>> conversations that shape the rapidly evolving mobile landscape. Sign up now.
>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Jolie-devel mailing list
>> Jol...@li...
>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
|
|
From: Matthias D. W. <mwa...@ya...> - 2013-11-21 11:30:00
Attachments:
jolie_doc.diff
|
Hi Fabrizio & Saverio,
I would propose some doc change to clear this one - since it did not
seem obvious to me.
Cheers,
Matthias
Matthias Dieter Wallnöfer schrieb:
> Hi Fabrizio,
>
> this works well, but on the client side
>> main
>> {
>> twice@TwiceService( 5 )
>> }
> I get a Java EOF exception. I imagine that this could be a coordination
> issue?
>> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning
>> WARNING: [client.ol] java.io.EOFException
>> at java.io.DataInputStream.readFully(DataInputStream.java:197)
>> at java.io.DataInputStream.readLong(DataInputStream.java:416)
>> at jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252)
>> at jolie.net.SodepProtocol.recv(SodepProtocol.java:305)
>> at jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92)
>> at jolie.net.CommChannel.recv(CommChannel.java:198)
>> at
>> jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226)
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>> at java.lang.Thread.run(Thread.java:724)
> Cheers,
> Matthias
>
> Fabrizio Montesi schrieb:
>> Hi Matthias,
>> this:
>>> twice( number ) {
>>> result = number * 2;
>>> println@Console( result )();
>>> }
>> is not a construct in the language. Request-Response operations
>> support the { block } construct because it is useful to specify
>> something to happen *in-between* the request and the response. For
>> one-ways this is not necessary because they just receive something.
>> Hence you can just use the semicolon operator for expressing a
>> sequence and obtain what you want:
>>
>> twice( number );
>> result = number * 2;
>> println@Console( result )()
>>
>>
>> Cheers,
>> Fabrizio.
>>
>>
>> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer
>> <mwa...@ya...> wrote:
>>> Hi developers,
>>>
>>> I got another question: in
>>> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment
>>> we have a simple client-server example:
>>>> |main|
>>>> |{|
>>>> |||twice( number )( response ) {|
>>>> |||response = number * ||2|
>>>> |||}|
>>>> |}|
>>> But when I change it to be one-way I run into trouble:
>>>> interface TwiceInterface {
>>>> OneWay: twice( int )
>>>> }
>>> and
>>>> main
>>>> {
>>>> twice( number ) {
>>>> result = number * 2;
>>>> println@Console( result )();
>>>> }
>>>> }
>>> does not work. Why?
>>>
>>> Do I need something like this?
>>>> main
>>>> {
>>>> [ twice( number ) ] {
>>>> result = number * 2;
>>>> println@Console( result )();
>>>> }
>>>> }
>>> Cheers,
>>> Matthias
>>>
>>> ------------------------------------------------------------------------------
>>> Shape the Mobile Experience: Free Subscription
>>> Software experts and developers: Be at the forefront of tech innovation.
>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing
>>> conversations that shape the rapidly evolving mobile landscape. Sign up now.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Jolie-devel mailing list
>>> Jol...@li...
>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> Jolie-devel mailing list
> Jol...@li...
> https://lists.sourceforge.net/lists/listinfo/jolie-devel
|
|
From: Fabrizio M. <fam...@gm...> - 2013-11-21 12:25:34
|
Seems OK! Saverio, is it possible to put it as an aside tip, not to
confuse the reader?
Also, "would be defined" => "were defined"
- Fabrizio
On Thu, Nov 21, 2013 at 12:29 PM, Matthias Dieter Wallnöfer
<mwa...@ya...> wrote:
> Hi Fabrizio & Saverio,
>
> I would propose some doc change to clear this one - since it did not seem
> obvious to me.
>
> Cheers,
> Matthias
>
> Matthias Dieter Wallnöfer schrieb:
>>
>> Hi Fabrizio,
>>
>> this works well, but on the client side
>>>
>>> main
>>> {
>>> twice@TwiceService( 5 )
>>> }
>>
>> I get a Java EOF exception. I imagine that this could be a coordination
>> issue?
>>>
>>> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning
>>> WARNING: [client.ol] java.io.EOFException
>>> at java.io.DataInputStream.readFully(DataInputStream.java:197)
>>> at java.io.DataInputStream.readLong(DataInputStream.java:416)
>>> at jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252)
>>> at jolie.net.SodepProtocol.recv(SodepProtocol.java:305)
>>> at jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92)
>>> at jolie.net.CommChannel.recv(CommChannel.java:198)
>>> at
>>>
>>> jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226)
>>> at
>>>
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>> at
>>>
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>> at java.lang.Thread.run(Thread.java:724)
>>
>> Cheers,
>> Matthias
>>
>> Fabrizio Montesi schrieb:
>>>
>>> Hi Matthias,
>>> this:
>>>>
>>>> twice( number ) {
>>>> result = number * 2;
>>>> println@Console( result )();
>>>> }
>>>
>>> is not a construct in the language. Request-Response operations
>>> support the { block } construct because it is useful to specify
>>> something to happen *in-between* the request and the response. For
>>> one-ways this is not necessary because they just receive something.
>>> Hence you can just use the semicolon operator for expressing a
>>> sequence and obtain what you want:
>>>
>>> twice( number );
>>> result = number * 2;
>>> println@Console( result )()
>>>
>>>
>>> Cheers,
>>> Fabrizio.
>>>
>>>
>>> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer
>>> <mwa...@ya...> wrote:
>>>>
>>>> Hi developers,
>>>>
>>>> I got another question: in
>>>>
>>>> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment
>>>> we have a simple client-server example:
>>>>>
>>>>> |main|
>>>>> |{|
>>>>> |||twice( number )( response ) {|
>>>>> |||response = number * ||2|
>>>>> |||}|
>>>>> |}|
>>>>
>>>> But when I change it to be one-way I run into trouble:
>>>>>
>>>>> interface TwiceInterface {
>>>>> OneWay: twice( int )
>>>>> }
>>>>
>>>> and
>>>>>
>>>>> main
>>>>> {
>>>>> twice( number ) {
>>>>> result = number * 2;
>>>>> println@Console( result )();
>>>>> }
>>>>> }
>>>>
>>>> does not work. Why?
>>>>
>>>> Do I need something like this?
>>>>>
>>>>> main
>>>>> {
>>>>> [ twice( number ) ] {
>>>>> result = number * 2;
>>>>> println@Console( result )();
>>>>> }
>>>>> }
>>>>
>>>> Cheers,
>>>> Matthias
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Shape the Mobile Experience: Free Subscription
>>>> Software experts and developers: Be at the forefront of tech innovation.
>>>> Intel(R) Software Adrenaline delivers strategic insight and
>>>> game-changing
>>>> conversations that shape the rapidly evolving mobile landscape. Sign up
>>>> now.
>>>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Jolie-devel mailing list
>>>> Jol...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Shape the Mobile Experience: Free Subscription
>> Software experts and developers: Be at the forefront of tech innovation.
>> Intel(R) Software Adrenaline delivers strategic insight and game-changing
>> conversations that shape the rapidly evolving mobile landscape. Sign up
>> now.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Jolie-devel mailing list
>> Jol...@li...
>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>
>
|
|
From: Saverio G. <sav...@gm...> - 2013-11-21 13:25:08
|
Ok,
I will sort out something.
SG
2013/11/21 Fabrizio Montesi <fam...@gm...>
> Seems OK! Saverio, is it possible to put it as an aside tip, not to
> confuse the reader?
>
> Also, "would be defined" => "were defined"
>
>
> - Fabrizio
>
> On Thu, Nov 21, 2013 at 12:29 PM, Matthias Dieter Wallnöfer
> <mwa...@ya...> wrote:
> > Hi Fabrizio & Saverio,
> >
> > I would propose some doc change to clear this one - since it did not seem
> > obvious to me.
> >
> > Cheers,
> > Matthias
> >
> > Matthias Dieter Wallnöfer schrieb:
> >>
> >> Hi Fabrizio,
> >>
> >> this works well, but on the client side
> >>>
> >>> main
> >>> {
> >>> twice@TwiceService( 5 )
> >>> }
> >>
> >> I get a Java EOF exception. I imagine that this could be a coordination
> >> issue?
> >>>
> >>> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning
> >>> WARNING: [client.ol] java.io.EOFException
> >>> at java.io.DataInputStream.readFully(DataInputStream.java:197)
> >>> at java.io.DataInputStream.readLong(DataInputStream.java:416)
> >>> at jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252)
> >>> at jolie.net.SodepProtocol.recv(SodepProtocol.java:305)
> >>> at jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92)
> >>> at jolie.net.CommChannel.recv(CommChannel.java:198)
> >>> at
> >>>
> >>>
> jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226)
> >>> at
> >>>
> >>>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> >>> at
> >>>
> >>>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> >>> at java.lang.Thread.run(Thread.java:724)
> >>
> >> Cheers,
> >> Matthias
> >>
> >> Fabrizio Montesi schrieb:
> >>>
> >>> Hi Matthias,
> >>> this:
> >>>>
> >>>> twice( number ) {
> >>>> result = number * 2;
> >>>> println@Console( result )();
> >>>> }
> >>>
> >>> is not a construct in the language. Request-Response operations
> >>> support the { block } construct because it is useful to specify
> >>> something to happen *in-between* the request and the response. For
> >>> one-ways this is not necessary because they just receive something.
> >>> Hence you can just use the semicolon operator for expressing a
> >>> sequence and obtain what you want:
> >>>
> >>> twice( number );
> >>> result = number * 2;
> >>> println@Console( result )()
> >>>
> >>>
> >>> Cheers,
> >>> Fabrizio.
> >>>
> >>>
> >>> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer
> >>> <mwa...@ya...> wrote:
> >>>>
> >>>> Hi developers,
> >>>>
> >>>> I got another question: in
> >>>>
> >>>>
> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment
> >>>> we have a simple client-server example:
> >>>>>
> >>>>> |main|
> >>>>> |{|
> >>>>> |||twice( number )( response ) {|
> >>>>> |||response = number * ||2|
> >>>>> |||}|
> >>>>> |}|
> >>>>
> >>>> But when I change it to be one-way I run into trouble:
> >>>>>
> >>>>> interface TwiceInterface {
> >>>>> OneWay: twice( int )
> >>>>> }
> >>>>
> >>>> and
> >>>>>
> >>>>> main
> >>>>> {
> >>>>> twice( number ) {
> >>>>> result = number * 2;
> >>>>> println@Console( result )();
> >>>>> }
> >>>>> }
> >>>>
> >>>> does not work. Why?
> >>>>
> >>>> Do I need something like this?
> >>>>>
> >>>>> main
> >>>>> {
> >>>>> [ twice( number ) ] {
> >>>>> result = number * 2;
> >>>>> println@Console( result )();
> >>>>> }
> >>>>> }
> >>>>
> >>>> Cheers,
> >>>> Matthias
> >>>>
> >>>>
> >>>>
> ------------------------------------------------------------------------------
> >>>> Shape the Mobile Experience: Free Subscription
> >>>> Software experts and developers: Be at the forefront of tech
> innovation.
> >>>> Intel(R) Software Adrenaline delivers strategic insight and
> >>>> game-changing
> >>>> conversations that shape the rapidly evolving mobile landscape. Sign
> up
> >>>> now.
> >>>>
> >>>>
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> >>>> _______________________________________________
> >>>> Jolie-devel mailing list
> >>>> Jol...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Shape the Mobile Experience: Free Subscription
> >> Software experts and developers: Be at the forefront of tech innovation.
> >> Intel(R) Software Adrenaline delivers strategic insight and
> game-changing
> >> conversations that shape the rapidly evolving mobile landscape. Sign up
> >> now.
> >>
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> Jolie-devel mailing list
> >> Jol...@li...
> >> https://lists.sourceforge.net/lists/listinfo/jolie-devel
> >
> >
>
|
|
From: Saverio G. <sav...@gm...> - 2013-11-21 15:10:17
|
Matthias, Fabrizio and I had a talk and sorted out that what you highlighted is an important lack in the documentation which is the description of the syntax and some examples of the usage of one-way and request-response operations. My proposal is to add a section after "Creating a communication port"[1] that specifies how ports are used for input/output (via operations). If you have any ideas or want to write a first draft to discuss on you are very welcome :) [1] http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=basics/communication_ports#creating-a-communication-port 2013/11/21 Saverio Giallorenzo <sav...@gm...> > Ok, > I will sort out something. > > SG > > > 2013/11/21 Fabrizio Montesi <fam...@gm...> > >> Seems OK! Saverio, is it possible to put it as an aside tip, not to >> confuse the reader? >> >> Also, "would be defined" => "were defined" >> >> >> - Fabrizio >> >> On Thu, Nov 21, 2013 at 12:29 PM, Matthias Dieter Wallnöfer >> <mwa...@ya...> wrote: >> > Hi Fabrizio & Saverio, >> > >> > I would propose some doc change to clear this one - since it did not >> seem >> > obvious to me. >> > >> > Cheers, >> > Matthias >> > >> > Matthias Dieter Wallnöfer schrieb: >> >> >> >> Hi Fabrizio, >> >> >> >> this works well, but on the client side >> >>> >> >>> main >> >>> { >> >>> twice@TwiceService( 5 ) >> >>> } >> >> >> >> I get a Java EOF exception. I imagine that this could be a coordination >> >> issue? >> >>> >> >>> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning >> >>> WARNING: [client.ol] java.io.EOFException >> >>> at java.io.DataInputStream.readFully(DataInputStream.java:197) >> >>> at java.io.DataInputStream.readLong(DataInputStream.java:416) >> >>> at jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252) >> >>> at jolie.net.SodepProtocol.recv(SodepProtocol.java:305) >> >>> at >> jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92) >> >>> at jolie.net.CommChannel.recv(CommChannel.java:198) >> >>> at >> >>> >> >>> >> jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226) >> >>> at >> >>> >> >>> >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >> >>> at >> >>> >> >>> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >> >>> at java.lang.Thread.run(Thread.java:724) >> >> >> >> Cheers, >> >> Matthias >> >> >> >> Fabrizio Montesi schrieb: >> >>> >> >>> Hi Matthias, >> >>> this: >> >>>> >> >>>> twice( number ) { >> >>>> result = number * 2; >> >>>> println@Console( result )(); >> >>>> } >> >>> >> >>> is not a construct in the language. Request-Response operations >> >>> support the { block } construct because it is useful to specify >> >>> something to happen *in-between* the request and the response. For >> >>> one-ways this is not necessary because they just receive something. >> >>> Hence you can just use the semicolon operator for expressing a >> >>> sequence and obtain what you want: >> >>> >> >>> twice( number ); >> >>> result = number * 2; >> >>> println@Console( result )() >> >>> >> >>> >> >>> Cheers, >> >>> Fabrizio. >> >>> >> >>> >> >>> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer >> >>> <mwa...@ya...> wrote: >> >>>> >> >>>> Hi developers, >> >>>> >> >>>> I got another question: in >> >>>> >> >>>> >> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment >> >>>> we have a simple client-server example: >> >>>>> >> >>>>> |main| >> >>>>> |{| >> >>>>> |||twice( number )( response ) {| >> >>>>> |||response = number * ||2| >> >>>>> |||}| >> >>>>> |}| >> >>>> >> >>>> But when I change it to be one-way I run into trouble: >> >>>>> >> >>>>> interface TwiceInterface { >> >>>>> OneWay: twice( int ) >> >>>>> } >> >>>> >> >>>> and >> >>>>> >> >>>>> main >> >>>>> { >> >>>>> twice( number ) { >> >>>>> result = number * 2; >> >>>>> println@Console( result )(); >> >>>>> } >> >>>>> } >> >>>> >> >>>> does not work. Why? >> >>>> >> >>>> Do I need something like this? >> >>>>> >> >>>>> main >> >>>>> { >> >>>>> [ twice( number ) ] { >> >>>>> result = number * 2; >> >>>>> println@Console( result )(); >> >>>>> } >> >>>>> } >> >>>> >> >>>> Cheers, >> >>>> Matthias >> >>>> >> >>>> >> >>>> >> ------------------------------------------------------------------------------ >> >>>> Shape the Mobile Experience: Free Subscription >> >>>> Software experts and developers: Be at the forefront of tech >> innovation. >> >>>> Intel(R) Software Adrenaline delivers strategic insight and >> >>>> game-changing >> >>>> conversations that shape the rapidly evolving mobile landscape. Sign >> up >> >>>> now. >> >>>> >> >>>> >> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >> >>>> _______________________________________________ >> >>>> Jolie-devel mailing list >> >>>> Jol...@li... >> >>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Shape the Mobile Experience: Free Subscription >> >> Software experts and developers: Be at the forefront of tech >> innovation. >> >> Intel(R) Software Adrenaline delivers strategic insight and >> game-changing >> >> conversations that shape the rapidly evolving mobile landscape. Sign up >> >> now. >> >> >> >> >> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >> >> _______________________________________________ >> >> Jolie-devel mailing list >> >> Jol...@li... >> >> https://lists.sourceforge.net/lists/listinfo/jolie-devel >> > >> > >> > > |
|
From: Matthias D. W. <mwa...@ya...> - 2013-11-21 16:54:48
|
Indeed, this would be a good idea. Cheers, Matthias Saverio Giallorenzo schrieb: > My proposal is to add a section after "Creating a communication port"[1] > that specifies how ports are used for input/output (via operations). > If you have any ideas or want to write a first draft to discuss on > you are very welcome :) > > [1] > http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=basics/communication_ports#creating-a-communication-port > > > > 2013/11/21 Saverio Giallorenzo <sav...@gm... > <mailto:sav...@gm...>> > > Ok, > I will sort out something. > > SG > > > 2013/11/21 Fabrizio Montesi <fam...@gm... > <mailto:fam...@gm...>> > > Seems OK! Saverio, is it possible to put it as an aside tip, > not to > confuse the reader? > > Also, "would be defined" => "were defined" > > > - Fabrizio > > On Thu, Nov 21, 2013 at 12:29 PM, Matthias Dieter Wallnöfer > <mwa...@ya... <mailto:mwa...@ya...>> wrote: > > Hi Fabrizio & Saverio, > > > > I would propose some doc change to clear this one - since it > did not seem > > obvious to me. > > > > Cheers, > > Matthias > > > > Matthias Dieter Wallnöfer schrieb: > >> > >> Hi Fabrizio, > >> > >> this works well, but on the client side > >>> > >>> main > >>> { > >>> twice@TwiceService( 5 ) > >>> } > >> > >> I get a Java EOF exception. I imagine that this could be a > coordination > >> issue? > >>> > >>> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning > >>> WARNING: [client.ol] java.io.EOFException > >>> at > java.io.DataInputStream.readFully(DataInputStream.java:197) > >>> at > java.io.DataInputStream.readLong(DataInputStream.java:416) > >>> at > jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252) > >>> at jolie.net.SodepProtocol.recv(SodepProtocol.java:305) > >>> at > jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92) > >>> at jolie.net.CommChannel.recv(CommChannel.java:198) > >>> at > >>> > >>> > jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226) > >>> at > >>> > >>> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > >>> at > >>> > >>> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > >>> at java.lang.Thread.run(Thread.java:724) > >> > >> Cheers, > >> Matthias > >> > >> Fabrizio Montesi schrieb: > >>> > >>> Hi Matthias, > >>> this: > >>>> > >>>> twice( number ) { > >>>> result = number * 2; > >>>> println@Console( result )(); > >>>> } > >>> > >>> is not a construct in the language. Request-Response > operations > >>> support the { block } construct because it is useful to > specify > >>> something to happen *in-between* the request and the > response. For > >>> one-ways this is not necessary because they just receive > something. > >>> Hence you can just use the semicolon operator for expressing a > >>> sequence and obtain what you want: > >>> > >>> twice( number ); > >>> result = number * 2; > >>> println@Console( result )() > >>> > >>> > >>> Cheers, > >>> Fabrizio. > >>> > >>> > >>> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer > >>> <mwa...@ya... <mailto:mwa...@ya...>> wrote: > >>>> > >>>> Hi developers, > >>>> > >>>> I got another question: in > >>>> > >>>> > http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment > >>>> we have a simple client-server example: > >>>>> > >>>>> |main| > >>>>> |{| > >>>>> |||twice( number )( response ) {| > >>>>> |||response = number * ||2| > >>>>> |||}| > >>>>> |}| > >>>> > >>>> But when I change it to be one-way I run into trouble: > >>>>> > >>>>> interface TwiceInterface { > >>>>> OneWay: twice( int ) > >>>>> } > >>>> > >>>> and > >>>>> > >>>>> main > >>>>> { > >>>>> twice( number ) { > >>>>> result = number * 2; > >>>>> println@Console( result )(); > >>>>> } > >>>>> } > >>>> > >>>> does not work. Why? > >>>> > >>>> Do I need something like this? > >>>>> > >>>>> main > >>>>> { > >>>>> [ twice( number ) ] { > >>>>> result = number * 2; > >>>>> println@Console( result )(); > >>>>> } > >>>>> } > >>>> > >>>> Cheers, > >>>> Matthias > >>>> > >>>> > >>>> > ------------------------------------------------------------------------------ > >>>> Shape the Mobile Experience: Free Subscription > >>>> Software experts and developers: Be at the forefront of > tech innovation. > >>>> Intel(R) Software Adrenaline delivers strategic insight and > >>>> game-changing > >>>> conversations that shape the rapidly evolving mobile > landscape. Sign up > >>>> now. > >>>> > >>>> > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > >>>> _______________________________________________ > >>>> Jolie-devel mailing list > >>>> Jol...@li... > <mailto:Jol...@li...> > >>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel > >> > >> > >> > >> > ------------------------------------------------------------------------------ > >> Shape the Mobile Experience: Free Subscription > >> Software experts and developers: Be at the forefront of > tech innovation. > >> Intel(R) Software Adrenaline delivers strategic insight and > game-changing > >> conversations that shape the rapidly evolving mobile > landscape. Sign up > >> now. > >> > >> > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > >> _______________________________________________ > >> Jolie-devel mailing list > >> Jol...@li... > <mailto:Jol...@li...> > >> https://lists.sourceforge.net/lists/listinfo/jolie-devel > > > > > > > |
|
From: Fabrizio M. <fam...@gm...> - 2013-11-21 12:23:38
|
Hi Matthias,
yeah, we have an annoying bug that doesn't really hurt but appears
like that (just prints that on screen) depending on the underlying OS
and network. It is consistent when using localhost afaik.
Basically, every output port channel is handled by a separate thread,
that jolie.net.AbstractCommChannel$ResponseReceiver, which waits for
new messages on the channel and puts them in cache when the
interpreter is ready to receive a response for an operation (in the
case of one-way such responses are just ACKs that the messages have
been put in the channel cache on the other side).
So, you have that thread on the client waiting on the channel, and the
server suddenly goes down because it terminates execution. Then, the
client throws that exception.
The problem in handling this gracefully is that we should
differentiate between an EOFException that we get in the middle of
parsing a received message in a protocol (e.g., SODEP, but more in
general CommProtocol.recv()), or the same exception got when trying to
receive the first bit of information (which is your case if you look
at the source code at SodepProtocol.java:252).
Then, the protocol could throw a custom exception that we create
(ChannelClosedException?) representing a graceful channel closing and
catch it from jolie.net.AbstractCommChannel$ResponseReceiver.
Let me know if you'd be interested in tackling this.
Cheers,
Fabrizio.
On Thu, Nov 21, 2013 at 11:53 AM, Matthias Dieter Wallnöfer
<mwa...@ya...> wrote:
> Hi Fabrizio,
>
> this works well, but on the client side
>>
>> main
>> {
>> twice@TwiceService( 5 )
>> }
>
> I get a Java EOF exception. I imagine that this could be a coordination
> issue?
>>
>> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning
>> WARNING: [client.ol] java.io.EOFException
>> at java.io.DataInputStream.readFully(DataInputStream.java:197)
>> at java.io.DataInputStream.readLong(DataInputStream.java:416)
>> at jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252)
>> at jolie.net.SodepProtocol.recv(SodepProtocol.java:305)
>> at jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92)
>> at jolie.net.CommChannel.recv(CommChannel.java:198)
>> at
>> jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226)
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>> at java.lang.Thread.run(Thread.java:724)
>
> Cheers,
> Matthias
>
> Fabrizio Montesi schrieb:
>
>> Hi Matthias,
>> this:
>>>
>>> twice( number ) {
>>> result = number * 2;
>>> println@Console( result )();
>>> }
>>
>> is not a construct in the language. Request-Response operations
>> support the { block } construct because it is useful to specify
>> something to happen *in-between* the request and the response. For
>> one-ways this is not necessary because they just receive something.
>> Hence you can just use the semicolon operator for expressing a
>> sequence and obtain what you want:
>>
>> twice( number );
>> result = number * 2;
>> println@Console( result )()
>>
>>
>> Cheers,
>> Fabrizio.
>>
>>
>> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer
>> <mwa...@ya...> wrote:
>>>
>>> Hi developers,
>>>
>>> I got another question: in
>>>
>>> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment
>>> we have a simple client-server example:
>>>>
>>>> |main|
>>>> |{|
>>>> |||twice( number )( response ) {|
>>>> |||response = number * ||2|
>>>> |||}|
>>>> |}|
>>>
>>> But when I change it to be one-way I run into trouble:
>>>>
>>>> interface TwiceInterface {
>>>> OneWay: twice( int )
>>>> }
>>>
>>> and
>>>>
>>>> main
>>>> {
>>>> twice( number ) {
>>>> result = number * 2;
>>>> println@Console( result )();
>>>> }
>>>> }
>>>
>>> does not work. Why?
>>>
>>> Do I need something like this?
>>>>
>>>> main
>>>> {
>>>> [ twice( number ) ] {
>>>> result = number * 2;
>>>> println@Console( result )();
>>>> }
>>>> }
>>>
>>> Cheers,
>>> Matthias
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Shape the Mobile Experience: Free Subscription
>>> Software experts and developers: Be at the forefront of tech innovation.
>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing
>>> conversations that shape the rapidly evolving mobile landscape. Sign up
>>> now.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Jolie-devel mailing list
>>> Jol...@li...
>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>
>
|
|
From: Matthias D. W. <mwa...@ya...> - 2013-11-21 17:19:48
|
Hi Fabrizio,
yes, the easiest would be to extend ChannelClosedException from
EOFException? So very little changes would be necessary. Otherwise we
would need to extend each method's signature.
Cheers,
Matthias
Fabrizio Montesi schrieb:
> Hi Matthias,
> yeah, we have an annoying bug that doesn't really hurt but appears
> like that (just prints that on screen) depending on the underlying OS
> and network. It is consistent when using localhost afaik.
>
> Basically, every output port channel is handled by a separate thread,
> that jolie.net.AbstractCommChannel$ResponseReceiver, which waits for
> new messages on the channel and puts them in cache when the
> interpreter is ready to receive a response for an operation (in the
> case of one-way such responses are just ACKs that the messages have
> been put in the channel cache on the other side).
>
> So, you have that thread on the client waiting on the channel, and the
> server suddenly goes down because it terminates execution. Then, the
> client throws that exception.
>
> The problem in handling this gracefully is that we should
> differentiate between an EOFException that we get in the middle of
> parsing a received message in a protocol (e.g., SODEP, but more in
> general CommProtocol.recv()), or the same exception got when trying to
> receive the first bit of information (which is your case if you look
> at the source code at SodepProtocol.java:252).
> Then, the protocol could throw a custom exception that we create
> (ChannelClosedException?) representing a graceful channel closing and
> catch it from jolie.net.AbstractCommChannel$ResponseReceiver.
>
> Let me know if you'd be interested in tackling this.
>
> Cheers,
> Fabrizio.
>
> On Thu, Nov 21, 2013 at 11:53 AM, Matthias Dieter Wallnöfer
> <mwa...@ya...> wrote:
>> Hi Fabrizio,
>>
>> this works well, but on the client side
>>> main
>>> {
>>> twice@TwiceService( 5 )
>>> }
>> I get a Java EOF exception. I imagine that this could be a coordination
>> issue?
>>> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning
>>> WARNING: [client.ol] java.io.EOFException
>>> at java.io.DataInputStream.readFully(DataInputStream.java:197)
>>> at java.io.DataInputStream.readLong(DataInputStream.java:416)
>>> at jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252)
>>> at jolie.net.SodepProtocol.recv(SodepProtocol.java:305)
>>> at jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92)
>>> at jolie.net.CommChannel.recv(CommChannel.java:198)
>>> at
>>> jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>> at java.lang.Thread.run(Thread.java:724)
>> Cheers,
>> Matthias
>>
>> Fabrizio Montesi schrieb:
>>
>>> Hi Matthias,
>>> this:
>>>> twice( number ) {
>>>> result = number * 2;
>>>> println@Console( result )();
>>>> }
>>> is not a construct in the language. Request-Response operations
>>> support the { block } construct because it is useful to specify
>>> something to happen *in-between* the request and the response. For
>>> one-ways this is not necessary because they just receive something.
>>> Hence you can just use the semicolon operator for expressing a
>>> sequence and obtain what you want:
>>>
>>> twice( number );
>>> result = number * 2;
>>> println@Console( result )()
>>>
>>>
>>> Cheers,
>>> Fabrizio.
>>>
>>>
>>> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer
>>> <mwa...@ya...> wrote:
>>>> Hi developers,
>>>>
>>>> I got another question: in
>>>>
>>>> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment
>>>> we have a simple client-server example:
>>>>> |main|
>>>>> |{|
>>>>> |||twice( number )( response ) {|
>>>>> |||response = number * ||2|
>>>>> |||}|
>>>>> |}|
>>>> But when I change it to be one-way I run into trouble:
>>>>> interface TwiceInterface {
>>>>> OneWay: twice( int )
>>>>> }
>>>> and
>>>>> main
>>>>> {
>>>>> twice( number ) {
>>>>> result = number * 2;
>>>>> println@Console( result )();
>>>>> }
>>>>> }
>>>> does not work. Why?
>>>>
>>>> Do I need something like this?
>>>>> main
>>>>> {
>>>>> [ twice( number ) ] {
>>>>> result = number * 2;
>>>>> println@Console( result )();
>>>>> }
>>>>> }
>>>> Cheers,
>>>> Matthias
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Shape the Mobile Experience: Free Subscription
>>>> Software experts and developers: Be at the forefront of tech innovation.
>>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing
>>>> conversations that shape the rapidly evolving mobile landscape. Sign up
>>>> now.
>>>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Jolie-devel mailing list
>>>> Jol...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>>
|
|
From: Matthias D. W. <mwa...@ya...> - 2013-11-29 09:08:29
|
Any news on this one?
Matthias Dieter Wallnöfer schrieb:
> Hi Fabrizio,
>
> yes, the easiest would be to extend ChannelClosedException from
> EOFException? So very little changes would be necessary. Otherwise we
> would need to extend each method's signature.
>
> Cheers,
> Matthias
>
> Fabrizio Montesi schrieb:
>> Hi Matthias,
>> yeah, we have an annoying bug that doesn't really hurt but appears
>> like that (just prints that on screen) depending on the underlying OS
>> and network. It is consistent when using localhost afaik.
>>
>> Basically, every output port channel is handled by a separate thread,
>> that jolie.net.AbstractCommChannel$ResponseReceiver, which waits for
>> new messages on the channel and puts them in cache when the
>> interpreter is ready to receive a response for an operation (in the
>> case of one-way such responses are just ACKs that the messages have
>> been put in the channel cache on the other side).
>>
>> So, you have that thread on the client waiting on the channel, and the
>> server suddenly goes down because it terminates execution. Then, the
>> client throws that exception.
>>
>> The problem in handling this gracefully is that we should
>> differentiate between an EOFException that we get in the middle of
>> parsing a received message in a protocol (e.g., SODEP, but more in
>> general CommProtocol.recv()), or the same exception got when trying to
>> receive the first bit of information (which is your case if you look
>> at the source code at SodepProtocol.java:252).
>> Then, the protocol could throw a custom exception that we create
>> (ChannelClosedException?) representing a graceful channel closing and
>> catch it from jolie.net.AbstractCommChannel$ResponseReceiver.
>>
>> Let me know if you'd be interested in tackling this.
>>
>> Cheers,
>> Fabrizio.
>>
>> On Thu, Nov 21, 2013 at 11:53 AM, Matthias Dieter Wallnöfer
>> <mwa...@ya...> wrote:
>>> Hi Fabrizio,
>>>
>>> this works well, but on the client side
>>>> main
>>>> {
>>>> twice@TwiceService( 5 )
>>>> }
>>> I get a Java EOF exception. I imagine that this could be a coordination
>>> issue?
>>>> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning
>>>> WARNING: [client.ol] java.io.EOFException
>>>> at java.io.DataInputStream.readFully(DataInputStream.java:197)
>>>> at java.io.DataInputStream.readLong(DataInputStream.java:416)
>>>> at jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252)
>>>> at jolie.net.SodepProtocol.recv(SodepProtocol.java:305)
>>>> at jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92)
>>>> at jolie.net.CommChannel.recv(CommChannel.java:198)
>>>> at
>>>> jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226)
>>>> at
>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>>> at
>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>>> at java.lang.Thread.run(Thread.java:724)
>>> Cheers,
>>> Matthias
>>>
>>> Fabrizio Montesi schrieb:
>>>
>>>> Hi Matthias,
>>>> this:
>>>>> twice( number ) {
>>>>> result = number * 2;
>>>>> println@Console( result )();
>>>>> }
>>>> is not a construct in the language. Request-Response operations
>>>> support the { block } construct because it is useful to specify
>>>> something to happen *in-between* the request and the response. For
>>>> one-ways this is not necessary because they just receive something.
>>>> Hence you can just use the semicolon operator for expressing a
>>>> sequence and obtain what you want:
>>>>
>>>> twice( number );
>>>> result = number * 2;
>>>> println@Console( result )()
>>>>
>>>>
>>>> Cheers,
>>>> Fabrizio.
>>>>
>>>>
>>>> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer
>>>> <mwa...@ya...> wrote:
>>>>> Hi developers,
>>>>>
>>>>> I got another question: in
>>>>>
>>>>> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment
>>>>> we have a simple client-server example:
>>>>>> |main|
>>>>>> |{|
>>>>>> |||twice( number )( response ) {|
>>>>>> |||response = number * ||2|
>>>>>> |||}|
>>>>>> |}|
>>>>> But when I change it to be one-way I run into trouble:
>>>>>> interface TwiceInterface {
>>>>>> OneWay: twice( int )
>>>>>> }
>>>>> and
>>>>>> main
>>>>>> {
>>>>>> twice( number ) {
>>>>>> result = number * 2;
>>>>>> println@Console( result )();
>>>>>> }
>>>>>> }
>>>>> does not work. Why?
>>>>>
>>>>> Do I need something like this?
>>>>>> main
>>>>>> {
>>>>>> [ twice( number ) ] {
>>>>>> result = number * 2;
>>>>>> println@Console( result )();
>>>>>> }
>>>>>> }
>>>>> Cheers,
>>>>> Matthias
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Shape the Mobile Experience: Free Subscription
>>>>> Software experts and developers: Be at the forefront of tech innovation.
>>>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing
>>>>> conversations that shape the rapidly evolving mobile landscape. Sign up
>>>>> now.
>>>>>
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>>>>> _______________________________________________
>>>>> Jolie-devel mailing list
>>>>> Jol...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> Jolie-devel mailing list
> Jol...@li...
> https://lists.sourceforge.net/lists/listinfo/jolie-devel
|
|
From: Fabrizio M. <fam...@gm...> - 2013-12-09 18:26:15
|
Hi Matthias,
sorry for the late reply, I've been pretty busy with my PhD.
Yes, I think that could work!
Wanna try change SODEPProtocol? I think that a possible fix could be
to catch EOFException there in the first read (that for the message
id) and rethrow it as a ChannelClosedException.
Cheers,
Fabrizio.
On Fri, Nov 29, 2013 at 10:08 AM, Matthias Dieter Wallnöfer
<mwa...@ya...> wrote:
> Any news on this one?
>
> Matthias Dieter Wallnöfer schrieb:
>
>> Hi Fabrizio,
>>
>> yes, the easiest would be to extend ChannelClosedException from
>> EOFException? So very little changes would be necessary. Otherwise we
>> would need to extend each method's signature.
>>
>> Cheers,
>> Matthias
>>
>> Fabrizio Montesi schrieb:
>>>
>>> Hi Matthias,
>>> yeah, we have an annoying bug that doesn't really hurt but appears
>>> like that (just prints that on screen) depending on the underlying OS
>>> and network. It is consistent when using localhost afaik.
>>>
>>> Basically, every output port channel is handled by a separate thread,
>>> that jolie.net.AbstractCommChannel$ResponseReceiver, which waits for
>>> new messages on the channel and puts them in cache when the
>>> interpreter is ready to receive a response for an operation (in the
>>> case of one-way such responses are just ACKs that the messages have
>>> been put in the channel cache on the other side).
>>>
>>> So, you have that thread on the client waiting on the channel, and the
>>> server suddenly goes down because it terminates execution. Then, the
>>> client throws that exception.
>>>
>>> The problem in handling this gracefully is that we should
>>> differentiate between an EOFException that we get in the middle of
>>> parsing a received message in a protocol (e.g., SODEP, but more in
>>> general CommProtocol.recv()), or the same exception got when trying to
>>> receive the first bit of information (which is your case if you look
>>> at the source code at SodepProtocol.java:252).
>>> Then, the protocol could throw a custom exception that we create
>>> (ChannelClosedException?) representing a graceful channel closing and
>>> catch it from jolie.net.AbstractCommChannel$ResponseReceiver.
>>>
>>> Let me know if you'd be interested in tackling this.
>>>
>>> Cheers,
>>> Fabrizio.
>>>
>>> On Thu, Nov 21, 2013 at 11:53 AM, Matthias Dieter Wallnöfer
>>> <mwa...@ya...> wrote:
>>>>
>>>> Hi Fabrizio,
>>>>
>>>> this works well, but on the client side
>>>>>
>>>>> main
>>>>> {
>>>>> twice@TwiceService( 5 )
>>>>> }
>>>>
>>>> I get a Java EOF exception. I imagine that this could be a coordination
>>>> issue?
>>>>>
>>>>> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning
>>>>> WARNING: [client.ol] java.io.EOFException
>>>>> at java.io.DataInputStream.readFully(DataInputStream.java:197)
>>>>> at java.io.DataInputStream.readLong(DataInputStream.java:416)
>>>>> at jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252)
>>>>> at jolie.net.SodepProtocol.recv(SodepProtocol.java:305)
>>>>> at
>>>>> jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92)
>>>>> at jolie.net.CommChannel.recv(CommChannel.java:198)
>>>>> at
>>>>>
>>>>> jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226)
>>>>> at
>>>>>
>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>>>> at
>>>>>
>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>>>> at java.lang.Thread.run(Thread.java:724)
>>>>
>>>> Cheers,
>>>> Matthias
>>>>
>>>> Fabrizio Montesi schrieb:
>>>>
>>>>> Hi Matthias,
>>>>> this:
>>>>>>
>>>>>> twice( number ) {
>>>>>> result = number * 2;
>>>>>> println@Console( result )();
>>>>>> }
>>>>>
>>>>> is not a construct in the language. Request-Response operations
>>>>> support the { block } construct because it is useful to specify
>>>>> something to happen *in-between* the request and the response. For
>>>>> one-ways this is not necessary because they just receive something.
>>>>> Hence you can just use the semicolon operator for expressing a
>>>>> sequence and obtain what you want:
>>>>>
>>>>> twice( number );
>>>>> result = number * 2;
>>>>> println@Console( result )()
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Fabrizio.
>>>>>
>>>>>
>>>>> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer
>>>>> <mwa...@ya...> wrote:
>>>>>>
>>>>>> Hi developers,
>>>>>>
>>>>>> I got another question: in
>>>>>>
>>>>>>
>>>>>> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment
>>>>>> we have a simple client-server example:
>>>>>>>
>>>>>>> |main|
>>>>>>> |{|
>>>>>>> |||twice( number )( response ) {|
>>>>>>> |||response = number * ||2|
>>>>>>> |||}|
>>>>>>> |}|
>>>>>>
>>>>>> But when I change it to be one-way I run into trouble:
>>>>>>>
>>>>>>> interface TwiceInterface {
>>>>>>> OneWay: twice( int )
>>>>>>> }
>>>>>>
>>>>>> and
>>>>>>>
>>>>>>> main
>>>>>>> {
>>>>>>> twice( number ) {
>>>>>>> result = number * 2;
>>>>>>> println@Console( result )();
>>>>>>> }
>>>>>>> }
>>>>>>
>>>>>> does not work. Why?
>>>>>>
>>>>>> Do I need something like this?
>>>>>>>
>>>>>>> main
>>>>>>> {
>>>>>>> [ twice( number ) ] {
>>>>>>> result = number * 2;
>>>>>>> println@Console( result )();
>>>>>>> }
>>>>>>> }
>>>>>>
>>>>>> Cheers,
>>>>>> Matthias
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Shape the Mobile Experience: Free Subscription
>>>>>> Software experts and developers: Be at the forefront of tech
>>>>>> innovation.
>>>>>> Intel(R) Software Adrenaline delivers strategic insight and
>>>>>> game-changing
>>>>>> conversations that shape the rapidly evolving mobile landscape. Sign
>>>>>> up
>>>>>> now.
>>>>>>
>>>>>>
>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>>>>>> _______________________________________________
>>>>>> Jolie-devel mailing list
>>>>>> Jol...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Shape the Mobile Experience: Free Subscription
>> Software experts and developers: Be at the forefront of tech innovation.
>> Intel(R) Software Adrenaline delivers strategic insight and game-changing
>> conversations that shape the rapidly evolving mobile landscape. Sign up
>> now.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Jolie-devel mailing list
>> Jol...@li...
>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>
>
|
|
From: Matthias D. W. <mwa...@ya...> - 2013-12-10 16:48:57
Attachments:
jolie_exception.diff
|
Hi,
this is a first idea. There is still something missing, since server and
client processes do not exit after a simple one-way communication message.
Matthias
Fabrizio Montesi schrieb:
> Hi Matthias,
> sorry for the late reply, I've been pretty busy with my PhD.
>
> Yes, I think that could work!
>
> Wanna try change SODEPProtocol? I think that a possible fix could be
> to catch EOFException there in the first read (that for the message
> id) and rethrow it as a ChannelClosedException.
>
> Cheers,
> Fabrizio.
>
> On Fri, Nov 29, 2013 at 10:08 AM, Matthias Dieter Wallnöfer
> <mwa...@ya...> wrote:
>> Any news on this one?
>>
>> Matthias Dieter Wallnöfer schrieb:
>>
>>> Hi Fabrizio,
>>>
>>> yes, the easiest would be to extend ChannelClosedException from
>>> EOFException? So very little changes would be necessary. Otherwise we
>>> would need to extend each method's signature.
>>>
>>> Cheers,
>>> Matthias
>>>
>>> Fabrizio Montesi schrieb:
>>>> Hi Matthias,
>>>> yeah, we have an annoying bug that doesn't really hurt but appears
>>>> like that (just prints that on screen) depending on the underlying OS
>>>> and network. It is consistent when using localhost afaik.
>>>>
>>>> Basically, every output port channel is handled by a separate thread,
>>>> that jolie.net.AbstractCommChannel$ResponseReceiver, which waits for
>>>> new messages on the channel and puts them in cache when the
>>>> interpreter is ready to receive a response for an operation (in the
>>>> case of one-way such responses are just ACKs that the messages have
>>>> been put in the channel cache on the other side).
>>>>
>>>> So, you have that thread on the client waiting on the channel, and the
>>>> server suddenly goes down because it terminates execution. Then, the
>>>> client throws that exception.
>>>>
>>>> The problem in handling this gracefully is that we should
>>>> differentiate between an EOFException that we get in the middle of
>>>> parsing a received message in a protocol (e.g., SODEP, but more in
>>>> general CommProtocol.recv()), or the same exception got when trying to
>>>> receive the first bit of information (which is your case if you look
>>>> at the source code at SodepProtocol.java:252).
>>>> Then, the protocol could throw a custom exception that we create
>>>> (ChannelClosedException?) representing a graceful channel closing and
>>>> catch it from jolie.net.AbstractCommChannel$ResponseReceiver.
>>>>
>>>> Let me know if you'd be interested in tackling this.
>>>>
>>>> Cheers,
>>>> Fabrizio.
>>>>
>>>> On Thu, Nov 21, 2013 at 11:53 AM, Matthias Dieter Wallnöfer
>>>> <mwa...@ya...> wrote:
>>>>> Hi Fabrizio,
>>>>>
>>>>> this works well, but on the client side
>>>>>> main
>>>>>> {
>>>>>> twice@TwiceService( 5 )
>>>>>> }
>>>>> I get a Java EOF exception. I imagine that this could be a coordination
>>>>> issue?
>>>>>> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning
>>>>>> WARNING: [client.ol] java.io.EOFException
>>>>>> at java.io.DataInputStream.readFully(DataInputStream.java:197)
>>>>>> at java.io.DataInputStream.readLong(DataInputStream.java:416)
>>>>>> at jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252)
>>>>>> at jolie.net.SodepProtocol.recv(SodepProtocol.java:305)
>>>>>> at
>>>>>> jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92)
>>>>>> at jolie.net.CommChannel.recv(CommChannel.java:198)
>>>>>> at
>>>>>>
>>>>>> jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226)
>>>>>> at
>>>>>>
>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>>>>> at
>>>>>>
>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>>>>> at java.lang.Thread.run(Thread.java:724)
>>>>> Cheers,
>>>>> Matthias
>>>>>
>>>>> Fabrizio Montesi schrieb:
>>>>>
>>>>>> Hi Matthias,
>>>>>> this:
>>>>>>> twice( number ) {
>>>>>>> result = number * 2;
>>>>>>> println@Console( result )();
>>>>>>> }
>>>>>> is not a construct in the language. Request-Response operations
>>>>>> support the { block } construct because it is useful to specify
>>>>>> something to happen *in-between* the request and the response. For
>>>>>> one-ways this is not necessary because they just receive something.
>>>>>> Hence you can just use the semicolon operator for expressing a
>>>>>> sequence and obtain what you want:
>>>>>>
>>>>>> twice( number );
>>>>>> result = number * 2;
>>>>>> println@Console( result )()
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Fabrizio.
>>>>>>
>>>>>>
>>>>>> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer
>>>>>> <mwa...@ya...> wrote:
>>>>>>> Hi developers,
>>>>>>>
>>>>>>> I got another question: in
>>>>>>>
>>>>>>>
>>>>>>> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment
>>>>>>> we have a simple client-server example:
>>>>>>>> |main|
>>>>>>>> |{|
>>>>>>>> |||twice( number )( response ) {|
>>>>>>>> |||response = number * ||2|
>>>>>>>> |||}|
>>>>>>>> |}|
>>>>>>> But when I change it to be one-way I run into trouble:
>>>>>>>> interface TwiceInterface {
>>>>>>>> OneWay: twice( int )
>>>>>>>> }
>>>>>>> and
>>>>>>>> main
>>>>>>>> {
>>>>>>>> twice( number ) {
>>>>>>>> result = number * 2;
>>>>>>>> println@Console( result )();
>>>>>>>> }
>>>>>>>> }
>>>>>>> does not work. Why?
>>>>>>>
>>>>>>> Do I need something like this?
>>>>>>>> main
>>>>>>>> {
>>>>>>>> [ twice( number ) ] {
>>>>>>>> result = number * 2;
>>>>>>>> println@Console( result )();
>>>>>>>> }
>>>>>>>> }
>>>>>>> Cheers,
>>>>>>> Matthias
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Shape the Mobile Experience: Free Subscription
>>>>>>> Software experts and developers: Be at the forefront of tech
>>>>>>> innovation.
>>>>>>> Intel(R) Software Adrenaline delivers strategic insight and
>>>>>>> game-changing
>>>>>>> conversations that shape the rapidly evolving mobile landscape. Sign
>>>>>>> up
>>>>>>> now.
>>>>>>>
>>>>>>>
>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>>>>>>> _______________________________________________
>>>>>>> Jolie-devel mailing list
>>>>>>> Jol...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Shape the Mobile Experience: Free Subscription
>>> Software experts and developers: Be at the forefront of tech innovation.
>>> Intel(R) Software Adrenaline delivers strategic insight and game-changing
>>> conversations that shape the rapidly evolving mobile landscape. Sign up
>>> now.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Jolie-devel mailing list
>>> Jol...@li...
>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>>
|
|
From: Fabrizio M. <fam...@gm...> - 2013-12-15 10:04:14
|
Hi Matthias,
generally, it looks fine, but what do you mean by "There is still
something missing, since server and client processes do not exit after
a simple one-way communication message." ?
Do you have a simple example that I can run to understand?
Cheers,
Fabrizio.
On Tue, Dec 10, 2013 at 5:48 PM, Matthias Dieter Wallnöfer
<mwa...@ya...> wrote:
> Hi,
>
> this is a first idea. There is still something missing, since server and
> client processes do not exit after a simple one-way communication message.
>
>
> Matthias
>
> Fabrizio Montesi schrieb:
>>
>> Hi Matthias,
>> sorry for the late reply, I've been pretty busy with my PhD.
>>
>> Yes, I think that could work!
>>
>> Wanna try change SODEPProtocol? I think that a possible fix could be
>> to catch EOFException there in the first read (that for the message
>> id) and rethrow it as a ChannelClosedException.
>>
>> Cheers,
>> Fabrizio.
>>
>> On Fri, Nov 29, 2013 at 10:08 AM, Matthias Dieter Wallnöfer
>> <mwa...@ya...> wrote:
>>>
>>> Any news on this one?
>>>
>>> Matthias Dieter Wallnöfer schrieb:
>>>
>>>> Hi Fabrizio,
>>>>
>>>> yes, the easiest would be to extend ChannelClosedException from
>>>> EOFException? So very little changes would be necessary. Otherwise we
>>>> would need to extend each method's signature.
>>>>
>>>> Cheers,
>>>> Matthias
>>>>
>>>> Fabrizio Montesi schrieb:
>>>>>
>>>>> Hi Matthias,
>>>>> yeah, we have an annoying bug that doesn't really hurt but appears
>>>>> like that (just prints that on screen) depending on the underlying OS
>>>>> and network. It is consistent when using localhost afaik.
>>>>>
>>>>> Basically, every output port channel is handled by a separate thread,
>>>>> that jolie.net.AbstractCommChannel$ResponseReceiver, which waits for
>>>>> new messages on the channel and puts them in cache when the
>>>>> interpreter is ready to receive a response for an operation (in the
>>>>> case of one-way such responses are just ACKs that the messages have
>>>>> been put in the channel cache on the other side).
>>>>>
>>>>> So, you have that thread on the client waiting on the channel, and the
>>>>> server suddenly goes down because it terminates execution. Then, the
>>>>> client throws that exception.
>>>>>
>>>>> The problem in handling this gracefully is that we should
>>>>> differentiate between an EOFException that we get in the middle of
>>>>> parsing a received message in a protocol (e.g., SODEP, but more in
>>>>> general CommProtocol.recv()), or the same exception got when trying to
>>>>> receive the first bit of information (which is your case if you look
>>>>> at the source code at SodepProtocol.java:252).
>>>>> Then, the protocol could throw a custom exception that we create
>>>>> (ChannelClosedException?) representing a graceful channel closing and
>>>>> catch it from jolie.net.AbstractCommChannel$ResponseReceiver.
>>>>>
>>>>> Let me know if you'd be interested in tackling this.
>>>>>
>>>>> Cheers,
>>>>> Fabrizio.
>>>>>
>>>>> On Thu, Nov 21, 2013 at 11:53 AM, Matthias Dieter Wallnöfer
>>>>> <mwa...@ya...> wrote:
>>>>>>
>>>>>> Hi Fabrizio,
>>>>>>
>>>>>> this works well, but on the client side
>>>>>>>
>>>>>>> main
>>>>>>> {
>>>>>>> twice@TwiceService( 5 )
>>>>>>> }
>>>>>>
>>>>>> I get a Java EOF exception. I imagine that this could be a
>>>>>> coordination
>>>>>> issue?
>>>>>>>
>>>>>>> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning
>>>>>>> WARNING: [client.ol] java.io.EOFException
>>>>>>> at java.io.DataInputStream.readFully(DataInputStream.java:197)
>>>>>>> at java.io.DataInputStream.readLong(DataInputStream.java:416)
>>>>>>> at jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252)
>>>>>>> at jolie.net.SodepProtocol.recv(SodepProtocol.java:305)
>>>>>>> at
>>>>>>> jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92)
>>>>>>> at jolie.net.CommChannel.recv(CommChannel.java:198)
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>>>> jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226)
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>>>>>> at
>>>>>>>
>>>>>>>
>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>>>>>> at java.lang.Thread.run(Thread.java:724)
>>>>>>
>>>>>> Cheers,
>>>>>> Matthias
>>>>>>
>>>>>> Fabrizio Montesi schrieb:
>>>>>>
>>>>>>> Hi Matthias,
>>>>>>> this:
>>>>>>>>
>>>>>>>> twice( number ) {
>>>>>>>> result = number * 2;
>>>>>>>> println@Console( result )();
>>>>>>>> }
>>>>>>>
>>>>>>> is not a construct in the language. Request-Response operations
>>>>>>> support the { block } construct because it is useful to specify
>>>>>>> something to happen *in-between* the request and the response. For
>>>>>>> one-ways this is not necessary because they just receive something.
>>>>>>> Hence you can just use the semicolon operator for expressing a
>>>>>>> sequence and obtain what you want:
>>>>>>>
>>>>>>> twice( number );
>>>>>>> result = number * 2;
>>>>>>> println@Console( result )()
>>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Fabrizio.
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer
>>>>>>> <mwa...@ya...> wrote:
>>>>>>>>
>>>>>>>> Hi developers,
>>>>>>>>
>>>>>>>> I got another question: in
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment
>>>>>>>> we have a simple client-server example:
>>>>>>>>>
>>>>>>>>> |main|
>>>>>>>>> |{|
>>>>>>>>> |||twice( number )( response ) {|
>>>>>>>>> |||response = number * ||2|
>>>>>>>>> |||}|
>>>>>>>>> |}|
>>>>>>>>
>>>>>>>> But when I change it to be one-way I run into trouble:
>>>>>>>>>
>>>>>>>>> interface TwiceInterface {
>>>>>>>>> OneWay: twice( int )
>>>>>>>>> }
>>>>>>>>
>>>>>>>> and
>>>>>>>>>
>>>>>>>>> main
>>>>>>>>> {
>>>>>>>>> twice( number ) {
>>>>>>>>> result = number * 2;
>>>>>>>>> println@Console( result )();
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>
>>>>>>>> does not work. Why?
>>>>>>>>
>>>>>>>> Do I need something like this?
>>>>>>>>>
>>>>>>>>> main
>>>>>>>>> {
>>>>>>>>> [ twice( number ) ] {
>>>>>>>>> result = number * 2;
>>>>>>>>> println@Console( result )();
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Matthias
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Shape the Mobile Experience: Free Subscription
>>>>>>>> Software experts and developers: Be at the forefront of tech
>>>>>>>> innovation.
>>>>>>>> Intel(R) Software Adrenaline delivers strategic insight and
>>>>>>>> game-changing
>>>>>>>> conversations that shape the rapidly evolving mobile landscape. Sign
>>>>>>>> up
>>>>>>>> now.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>>>>>>>> _______________________________________________
>>>>>>>> Jolie-devel mailing list
>>>>>>>> Jol...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Shape the Mobile Experience: Free Subscription
>>>> Software experts and developers: Be at the forefront of tech innovation.
>>>> Intel(R) Software Adrenaline delivers strategic insight and
>>>> game-changing
>>>> conversations that shape the rapidly evolving mobile landscape. Sign up
>>>> now.
>>>>
>>>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Jolie-devel mailing list
>>>> Jol...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>>>
>>>
>
|
|
From: Matthias D. W. <mwa...@ya...> - 2013-12-16 11:25:02
Attachments:
jolie_example.zip
|
Hi Fabrizio,
I notice that the client does not terminate anymore with my patch. The
attachment contains the simplest example.
Cheers,
Matthias
Fabrizio Montesi schrieb:
> Hi Matthias,
> generally, it looks fine, but what do you mean by "There is still
> something missing, since server and client processes do not exit after
> a simple one-way communication message." ?
>
> Do you have a simple example that I can run to understand?
>
> Cheers,
> Fabrizio.
>
> On Tue, Dec 10, 2013 at 5:48 PM, Matthias Dieter Wallnöfer
> <mwa...@ya...> wrote:
>> Hi,
>>
>> this is a first idea. There is still something missing, since server and
>> client processes do not exit after a simple one-way communication message.
>>
>>
>> Matthias
>>
>> Fabrizio Montesi schrieb:
>>> Hi Matthias,
>>> sorry for the late reply, I've been pretty busy with my PhD.
>>>
>>> Yes, I think that could work!
>>>
>>> Wanna try change SODEPProtocol? I think that a possible fix could be
>>> to catch EOFException there in the first read (that for the message
>>> id) and rethrow it as a ChannelClosedException.
>>>
>>> Cheers,
>>> Fabrizio.
>>>
>>> On Fri, Nov 29, 2013 at 10:08 AM, Matthias Dieter Wallnöfer
>>> <mwa...@ya...> wrote:
>>>> Any news on this one?
>>>>
>>>> Matthias Dieter Wallnöfer schrieb:
>>>>
>>>>> Hi Fabrizio,
>>>>>
>>>>> yes, the easiest would be to extend ChannelClosedException from
>>>>> EOFException? So very little changes would be necessary. Otherwise we
>>>>> would need to extend each method's signature.
>>>>>
>>>>> Cheers,
>>>>> Matthias
>>>>>
>>>>> Fabrizio Montesi schrieb:
>>>>>> Hi Matthias,
>>>>>> yeah, we have an annoying bug that doesn't really hurt but appears
>>>>>> like that (just prints that on screen) depending on the underlying OS
>>>>>> and network. It is consistent when using localhost afaik.
>>>>>>
>>>>>> Basically, every output port channel is handled by a separate thread,
>>>>>> that jolie.net.AbstractCommChannel$ResponseReceiver, which waits for
>>>>>> new messages on the channel and puts them in cache when the
>>>>>> interpreter is ready to receive a response for an operation (in the
>>>>>> case of one-way such responses are just ACKs that the messages have
>>>>>> been put in the channel cache on the other side).
>>>>>>
>>>>>> So, you have that thread on the client waiting on the channel, and the
>>>>>> server suddenly goes down because it terminates execution. Then, the
>>>>>> client throws that exception.
>>>>>>
>>>>>> The problem in handling this gracefully is that we should
>>>>>> differentiate between an EOFException that we get in the middle of
>>>>>> parsing a received message in a protocol (e.g., SODEP, but more in
>>>>>> general CommProtocol.recv()), or the same exception got when trying to
>>>>>> receive the first bit of information (which is your case if you look
>>>>>> at the source code at SodepProtocol.java:252).
>>>>>> Then, the protocol could throw a custom exception that we create
>>>>>> (ChannelClosedException?) representing a graceful channel closing and
>>>>>> catch it from jolie.net.AbstractCommChannel$ResponseReceiver.
>>>>>>
>>>>>> Let me know if you'd be interested in tackling this.
>>>>>>
>>>>>> Cheers,
>>>>>> Fabrizio.
>>>>>>
>>>>>> On Thu, Nov 21, 2013 at 11:53 AM, Matthias Dieter Wallnöfer
>>>>>> <mwa...@ya...> wrote:
>>>>>>> Hi Fabrizio,
>>>>>>>
>>>>>>> this works well, but on the client side
>>>>>>>> main
>>>>>>>> {
>>>>>>>> twice@TwiceService( 5 )
>>>>>>>> }
>>>>>>> I get a Java EOF exception. I imagine that this could be a
>>>>>>> coordination
>>>>>>> issue?
>>>>>>>> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning
>>>>>>>> WARNING: [client.ol] java.io.EOFException
>>>>>>>> at java.io.DataInputStream.readFully(DataInputStream.java:197)
>>>>>>>> at java.io.DataInputStream.readLong(DataInputStream.java:416)
>>>>>>>> at jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252)
>>>>>>>> at jolie.net.SodepProtocol.recv(SodepProtocol.java:305)
>>>>>>>> at
>>>>>>>> jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92)
>>>>>>>> at jolie.net.CommChannel.recv(CommChannel.java:198)
>>>>>>>> at
>>>>>>>>
>>>>>>>>
>>>>>>>> jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226)
>>>>>>>> at
>>>>>>>>
>>>>>>>>
>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>>>>>>> at
>>>>>>>>
>>>>>>>>
>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>>>>>>> at java.lang.Thread.run(Thread.java:724)
>>>>>>> Cheers,
>>>>>>> Matthias
>>>>>>>
>>>>>>> Fabrizio Montesi schrieb:
>>>>>>>
>>>>>>>> Hi Matthias,
>>>>>>>> this:
>>>>>>>>> twice( number ) {
>>>>>>>>> result = number * 2;
>>>>>>>>> println@Console( result )();
>>>>>>>>> }
>>>>>>>> is not a construct in the language. Request-Response operations
>>>>>>>> support the { block } construct because it is useful to specify
>>>>>>>> something to happen *in-between* the request and the response. For
>>>>>>>> one-ways this is not necessary because they just receive something.
>>>>>>>> Hence you can just use the semicolon operator for expressing a
>>>>>>>> sequence and obtain what you want:
>>>>>>>>
>>>>>>>> twice( number );
>>>>>>>> result = number * 2;
>>>>>>>> println@Console( result )()
>>>>>>>>
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Fabrizio.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer
>>>>>>>> <mwa...@ya...> wrote:
>>>>>>>>> Hi developers,
>>>>>>>>>
>>>>>>>>> I got another question: in
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment
>>>>>>>>> we have a simple client-server example:
>>>>>>>>>> |main|
>>>>>>>>>> |{|
>>>>>>>>>> |||twice( number )( response ) {|
>>>>>>>>>> |||response = number * ||2|
>>>>>>>>>> |||}|
>>>>>>>>>> |}|
>>>>>>>>> But when I change it to be one-way I run into trouble:
>>>>>>>>>> interface TwiceInterface {
>>>>>>>>>> OneWay: twice( int )
>>>>>>>>>> }
>>>>>>>>> and
>>>>>>>>>> main
>>>>>>>>>> {
>>>>>>>>>> twice( number ) {
>>>>>>>>>> result = number * 2;
>>>>>>>>>> println@Console( result )();
>>>>>>>>>> }
>>>>>>>>>> }
>>>>>>>>> does not work. Why?
>>>>>>>>>
>>>>>>>>> Do I need something like this?
>>>>>>>>>> main
>>>>>>>>>> {
>>>>>>>>>> [ twice( number ) ] {
>>>>>>>>>> result = number * 2;
>>>>>>>>>> println@Console( result )();
>>>>>>>>>> }
>>>>>>>>>> }
>>>>>>>>> Cheers,
>>>>>>>>> Matthias
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Shape the Mobile Experience: Free Subscription
>>>>>>>>> Software experts and developers: Be at the forefront of tech
>>>>>>>>> innovation.
>>>>>>>>> Intel(R) Software Adrenaline delivers strategic insight and
>>>>>>>>> game-changing
>>>>>>>>> conversations that shape the rapidly evolving mobile landscape. Sign
>>>>>>>>> up
>>>>>>>>> now.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>>>>>>>>> _______________________________________________
>>>>>>>>> Jolie-devel mailing list
>>>>>>>>> Jol...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Shape the Mobile Experience: Free Subscription
>>>>> Software experts and developers: Be at the forefront of tech innovation.
>>>>> Intel(R) Software Adrenaline delivers strategic insight and
>>>>> game-changing
>>>>> conversations that shape the rapidly evolving mobile landscape. Sign up
>>>>> now.
>>>>>
>>>>>
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>>>>> _______________________________________________
>>>>> Jolie-devel mailing list
>>>>> Jol...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>>>>
|
|
From: Fabrizio M. <fam...@gm...> - 2013-12-18 16:00:32
|
Thanks a lot for the example and the patch Matthias. Turns out that it
wasn't the client's fault, it was the server's!
Basically, the server was shutting down too early, without waiting for
the thread responsible for sending the acknowledgment of message
reception to the client to finish its duty correctly
(CommChannelHandler).
I've inserted a reader-writer lock to solve the problem: each
commchannelhandler is a reader and the interpreter exiting procedure
is the writer, so when the interpreter wants to terminate it has to
wait for all the "readers" to finish.
Client now works for me. Let me know if it works for you too.
Cheers,
Fabrizio.
On Mon, Dec 16, 2013 at 12:24 PM, Matthias Dieter Wallnöfer
<mwa...@ya...> wrote:
> Hi Fabrizio,
>
> I notice that the client does not terminate anymore with my patch. The
> attachment contains the simplest example.
>
>
> Cheers,
> Matthias
>
> Fabrizio Montesi schrieb:
>>
>> Hi Matthias,
>> generally, it looks fine, but what do you mean by "There is still
>> something missing, since server and client processes do not exit after
>> a simple one-way communication message." ?
>>
>> Do you have a simple example that I can run to understand?
>>
>> Cheers,
>> Fabrizio.
>>
>> On Tue, Dec 10, 2013 at 5:48 PM, Matthias Dieter Wallnöfer
>> <mwa...@ya...> wrote:
>>>
>>> Hi,
>>>
>>> this is a first idea. There is still something missing, since server and
>>> client processes do not exit after a simple one-way communication
>>> message.
>>>
>>>
>>> Matthias
>>>
>>> Fabrizio Montesi schrieb:
>>>>
>>>> Hi Matthias,
>>>> sorry for the late reply, I've been pretty busy with my PhD.
>>>>
>>>> Yes, I think that could work!
>>>>
>>>> Wanna try change SODEPProtocol? I think that a possible fix could be
>>>> to catch EOFException there in the first read (that for the message
>>>> id) and rethrow it as a ChannelClosedException.
>>>>
>>>> Cheers,
>>>> Fabrizio.
>>>>
>>>> On Fri, Nov 29, 2013 at 10:08 AM, Matthias Dieter Wallnöfer
>>>> <mwa...@ya...> wrote:
>>>>>
>>>>> Any news on this one?
>>>>>
>>>>> Matthias Dieter Wallnöfer schrieb:
>>>>>
>>>>>> Hi Fabrizio,
>>>>>>
>>>>>> yes, the easiest would be to extend ChannelClosedException from
>>>>>> EOFException? So very little changes would be necessary. Otherwise we
>>>>>> would need to extend each method's signature.
>>>>>>
>>>>>> Cheers,
>>>>>> Matthias
>>>>>>
>>>>>> Fabrizio Montesi schrieb:
>>>>>>>
>>>>>>> Hi Matthias,
>>>>>>> yeah, we have an annoying bug that doesn't really hurt but appears
>>>>>>> like that (just prints that on screen) depending on the underlying OS
>>>>>>> and network. It is consistent when using localhost afaik.
>>>>>>>
>>>>>>> Basically, every output port channel is handled by a separate thread,
>>>>>>> that jolie.net.AbstractCommChannel$ResponseReceiver, which waits for
>>>>>>> new messages on the channel and puts them in cache when the
>>>>>>> interpreter is ready to receive a response for an operation (in the
>>>>>>> case of one-way such responses are just ACKs that the messages have
>>>>>>> been put in the channel cache on the other side).
>>>>>>>
>>>>>>> So, you have that thread on the client waiting on the channel, and
>>>>>>> the
>>>>>>> server suddenly goes down because it terminates execution. Then, the
>>>>>>> client throws that exception.
>>>>>>>
>>>>>>> The problem in handling this gracefully is that we should
>>>>>>> differentiate between an EOFException that we get in the middle of
>>>>>>> parsing a received message in a protocol (e.g., SODEP, but more in
>>>>>>> general CommProtocol.recv()), or the same exception got when trying
>>>>>>> to
>>>>>>> receive the first bit of information (which is your case if you look
>>>>>>> at the source code at SodepProtocol.java:252).
>>>>>>> Then, the protocol could throw a custom exception that we create
>>>>>>> (ChannelClosedException?) representing a graceful channel closing and
>>>>>>> catch it from jolie.net.AbstractCommChannel$ResponseReceiver.
>>>>>>>
>>>>>>> Let me know if you'd be interested in tackling this.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Fabrizio.
>>>>>>>
>>>>>>> On Thu, Nov 21, 2013 at 11:53 AM, Matthias Dieter Wallnöfer
>>>>>>> <mwa...@ya...> wrote:
>>>>>>>>
>>>>>>>> Hi Fabrizio,
>>>>>>>>
>>>>>>>> this works well, but on the client side
>>>>>>>>>
>>>>>>>>> main
>>>>>>>>> {
>>>>>>>>> twice@TwiceService( 5 )
>>>>>>>>> }
>>>>>>>>
>>>>>>>> I get a Java EOF exception. I imagine that this could be a
>>>>>>>> coordination
>>>>>>>> issue?
>>>>>>>>>
>>>>>>>>> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning
>>>>>>>>> WARNING: [client.ol] java.io.EOFException
>>>>>>>>> at
>>>>>>>>> java.io.DataInputStream.readFully(DataInputStream.java:197)
>>>>>>>>> at
>>>>>>>>> java.io.DataInputStream.readLong(DataInputStream.java:416)
>>>>>>>>> at
>>>>>>>>> jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252)
>>>>>>>>> at jolie.net.SodepProtocol.recv(SodepProtocol.java:305)
>>>>>>>>> at
>>>>>>>>> jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92)
>>>>>>>>> at jolie.net.CommChannel.recv(CommChannel.java:198)
>>>>>>>>> at
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226)
>>>>>>>>> at
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>>>>>>>> at
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>>>>>>>> at java.lang.Thread.run(Thread.java:724)
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Matthias
>>>>>>>>
>>>>>>>> Fabrizio Montesi schrieb:
>>>>>>>>
>>>>>>>>> Hi Matthias,
>>>>>>>>> this:
>>>>>>>>>>
>>>>>>>>>> twice( number ) {
>>>>>>>>>> result = number * 2;
>>>>>>>>>> println@Console( result )();
>>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> is not a construct in the language. Request-Response operations
>>>>>>>>> support the { block } construct because it is useful to specify
>>>>>>>>> something to happen *in-between* the request and the response. For
>>>>>>>>> one-ways this is not necessary because they just receive something.
>>>>>>>>> Hence you can just use the semicolon operator for expressing a
>>>>>>>>> sequence and obtain what you want:
>>>>>>>>>
>>>>>>>>> twice( number );
>>>>>>>>> result = number * 2;
>>>>>>>>> println@Console( result )()
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Fabrizio.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer
>>>>>>>>> <mwa...@ya...> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi developers,
>>>>>>>>>>
>>>>>>>>>> I got another question: in
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment
>>>>>>>>>> we have a simple client-server example:
>>>>>>>>>>>
>>>>>>>>>>> |main|
>>>>>>>>>>> |{|
>>>>>>>>>>> |||twice( number )( response ) {|
>>>>>>>>>>> |||response = number * ||2|
>>>>>>>>>>> |||}|
>>>>>>>>>>> |}|
>>>>>>>>>>
>>>>>>>>>> But when I change it to be one-way I run into trouble:
>>>>>>>>>>>
>>>>>>>>>>> interface TwiceInterface {
>>>>>>>>>>> OneWay: twice( int )
>>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> and
>>>>>>>>>>>
>>>>>>>>>>> main
>>>>>>>>>>> {
>>>>>>>>>>> twice( number ) {
>>>>>>>>>>> result = number * 2;
>>>>>>>>>>> println@Console( result )();
>>>>>>>>>>> }
>>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> does not work. Why?
>>>>>>>>>>
>>>>>>>>>> Do I need something like this?
>>>>>>>>>>>
>>>>>>>>>>> main
>>>>>>>>>>> {
>>>>>>>>>>> [ twice( number ) ] {
>>>>>>>>>>> result = number * 2;
>>>>>>>>>>> println@Console( result )();
>>>>>>>>>>> }
>>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Matthias
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> Shape the Mobile Experience: Free Subscription
>>>>>>>>>> Software experts and developers: Be at the forefront of tech
>>>>>>>>>> innovation.
>>>>>>>>>> Intel(R) Software Adrenaline delivers strategic insight and
>>>>>>>>>> game-changing
>>>>>>>>>> conversations that shape the rapidly evolving mobile landscape.
>>>>>>>>>> Sign
>>>>>>>>>> up
>>>>>>>>>> now.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Jolie-devel mailing list
>>>>>>>>>> Jol...@li...
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Shape the Mobile Experience: Free Subscription
>>>>>> Software experts and developers: Be at the forefront of tech
>>>>>> innovation.
>>>>>> Intel(R) Software Adrenaline delivers strategic insight and
>>>>>> game-changing
>>>>>> conversations that shape the rapidly evolving mobile landscape. Sign
>>>>>> up
>>>>>> now.
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>>>>>> _______________________________________________
>>>>>> Jolie-devel mailing list
>>>>>> Jol...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>>>>>
>>>>>
>
|
|
From: Matthias D. W. <mwa...@ya...> - 2013-12-18 16:30:35
|
Hi Fabrizio, indeed it seems to work. I appreciate it very much that the various bugs get fixed :). I notice that Jolie is a very clever language. Cheers, Matthias Fabrizio Montesi schrieb: > Thanks a lot for the example and the patch Matthias. Turns out that it > wasn't the client's fault, it was the server's! > Basically, the server was shutting down too early, without waiting for > the thread responsible for sending the acknowledgment of message > reception to the client to finish its duty correctly > (CommChannelHandler). > > I've inserted a reader-writer lock to solve the problem: each > commchannelhandler is a reader and the interpreter exiting procedure > is the writer, so when the interpreter wants to terminate it has to > wait for all the "readers" to finish. > > Client now works for me. Let me know if it works for you too. > > Cheers, > Fabrizio. > |
Thanks for helping keep SourceForge clean.
X