Re: [infinispan-dev] Threadpools in a large cluster

[Bela Ban]

Hi Pedro,

this is almost exactly what I wanted to implement !

Question:
- In RequestCorrelator.handleRequest():

protected void handleRequest(Message req, Header hdr) {
Object retval;
boolean threwException = false;
MessageRequest messageRequest = new MessageRequestImpl(req, hdr);
try {
retval=request_handler.handle(messageRequest);
} catch(Throwable t) {
retval=t;
threwException = true;
}
messageRequest.sendReply(retval, threwException);// <-- should be moved 
up, or called only if threwException == true
}


, you create a MessageRequestImpl and pass it to the RequestHandler. The 
request handler then dispatches the request (possibly) to a thread pool 
and calls MessageRequestImpl.sendReply() when done.

However, you also call MessageRequest.sendReply() before returning from 
handleRequest(). I think this is an error, and 
MessageRequest.sendReply() should be moved up inside the catch clause, 
or be called only if threwException is true, so that we send a reply on 
behalf of the RequestHandler if and only if it threw an exception (e.g. 
before it dispatches the request to a thread pool). Otherwise, we'd send 
a reply *twice* !

A few changes I have in mind (need to think about it more):

- I want to leave the existing RequestHandler interface in place, so 
current implementation continue to work
- There will be a new AsyncRequestHandler interface (possibly extending 
RequestHandler, so an implementation can decide to implement both). The 
RequestCorrelator needs to have either request_handler or 
async_request_handler set. If the former is set, the logic is unchanged. 
If the latter is set I'll invoke the async dispatching code

- AsyncRequestHandler will look similar to the following:
void handle(Message request, Handback hb, boolean requires_response) 
throws Throwable;
- Handback is an interface, and its impl contains header information 
(e.g. request ID)
- Handback has a sendReply(Object reply, boolean is_exception) method 
which sends a response (or exception) back to the caller
- When requires_response is false, the AsyncRequestHandler doesn't need 
to invoke sendReply()

- Message batching
- The above interfaces need to take message batching into account, e.g. 
the ability to handle multiple requests concurrently (if they don't need 
to be executed sequentially)


Thoughts ?


On 2/6/13 8:29 PM, Pedro Ruivo wrote:
> Hi all,
>
> Recently I came up with a solution that can help with the thread pool 
> problem motivated by the following:
>
> In one of the first implementation of Total Order based commit 
> protocol (TO), I had the requirement to move the PrepareCommand to 
> another thread pool. In resume, the TO protocol delivers the 
> PrepareCommand in a deterministic order in all the nodes, by a single 
> deliver thread. To ensure consistency, if it delivers two conflicting 
> transactions, the second transaction must wait until the first 
> transaction finishes. However, blocking single deliver thread is not a 
> good solution, because no more transaction can be validated, even if 
> they don't conflict, while the thread is blocked.
>
> So, after creating a dependency graph (i.e. the second transaction 
> knows that it must wait for the first transaction to finish) I move 
> the PrepareCommand to another thread pool. Initially, I implemented a 
> new command, called PrepareResponseCommand, that sends back the reply 
> of the PrepareCommand. This solution has one disadvantage: I had to 
> implement an ack collector in ISPN, while JGroups already offers me 
> that with a synchronous communication.
>
> Recently (2 or 3 months ago) I implemented a simple modification in 
> JGroups. In a more generic approach, it allows other threads to reply 
> to a RPC request (such as the PrepareCommand). In the previous 
> scenario, I replaced the PrepareResponseCommand and the ack collector 
> implementation with a synchronous RPC invocation. I've used this 
> solution in other issues in the Cloud-TM's ISPN fork.
>
> This solution is quite simple to implement and may help you to move 
> the commands to ISPN internal thread pools. The modifications I've 
> made are the following:
>
> 1) I added a new interface (see [1]) that is sent to the application 
> instead of the Message object (see [4]). This interface contains the 
> Message and it has a method to allow the application send the reply to 
> that particular request.
> 2) I added a new object in [4] with the meaning: this return value is 
> not the reply to the RPC request. This is the returned value that I 
> return when I want to release the thread, because ISPN should return 
> some object in the handle() method. Of course, I know that ISPN will 
> invoke the sendReply() in some other place, otherwise, I will get a 
> TimeoutException in the sender side.
> 3) Also I've changed the RequestCorrelator implementation to support 
> the previous modifications (see [2] and [3])
>
> In the Cloud-TM's ISPN fork I added a reference in the 
> BaseCacheRpcCommand to

Re: [infinispan-dev] Codename for Infinispan 5.3.0

[Navin Surtani]

How about "Hopocalypse"?

http://beeradvocate.com/beer/profile/3835/46649/?ba=kaseydad


--Navin 


- Original Message -
From: "Zdeněk Henek" 
To: "infinispan -Dev List" 
Sent: Thursday, February 7, 2013 4:20:37 AM
Subject: Re: [infinispan-dev] Codename for Infinispan 5.3.0

Hi,
Hostan?

http://www.hostan.cz/

Z

On Wed, Feb 6, 2013 at 7:14 PM, Erik Salter  wrote:
> Being an American from Pennsylvania, it is state law that I suggest
> Yuengling (despite the fact I don't drink)
>
> -Original Message-
> From: infinispan-dev-boun...@lists.jboss.org
> [mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of Manik Surtani
> Sent: Wednesday, February 06, 2013 12:47 PM
> To: infinispan -Dev List
> Subject: Re: [infinispan-dev] Codename for Infinispan 5.3.0
>
> 5.2.0 is Delirium.
>
> https://github.com/infinispan/infinispan/blob/5.2.x/core/src/main/java/org/i
> nfinispan/Version.java#L45
>
> My vote - Dragonslayer
>
> http://www.banksandtaylor.com/dragonslayer.html
>
> - M
>
>
> On 6 Feb 2013, at 17:43, Sanne Grinovero  wrote:
>
>> Delirium Tremens
>>
>> very appropriate :-D
>>
>> On 6 February 2013 17:17, Mircea Markus  wrote:
>>> Following the tradition, please bring your suggestion of beer-code
>>> name for the new Infinispan release. Then we'll vote.
>>> Mine is  Guinness :-)
>>>
>>> Cheers,
>>> --
>>> Mircea Markus
>>> Infinispan lead (www.infinispan.org)
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> infinispan-dev mailing list
>>> infinispan-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> ___
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> ma...@jboss.org
> twitter.com/maniksurtani
>
> Platform Architect, JBoss Data Grid
> http://red.ht/data-grid
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Codename for Infinispan 5.3.0

[Zdeněk Henek]

Hi,
Hostan?

http://www.hostan.cz/

Z

On Wed, Feb 6, 2013 at 7:14 PM, Erik Salter  wrote:
> Being an American from Pennsylvania, it is state law that I suggest
> Yuengling (despite the fact I don't drink)
>
> -Original Message-
> From: infinispan-dev-boun...@lists.jboss.org
> [mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of Manik Surtani
> Sent: Wednesday, February 06, 2013 12:47 PM
> To: infinispan -Dev List
> Subject: Re: [infinispan-dev] Codename for Infinispan 5.3.0
>
> 5.2.0 is Delirium.
>
> https://github.com/infinispan/infinispan/blob/5.2.x/core/src/main/java/org/i
> nfinispan/Version.java#L45
>
> My vote - Dragonslayer
>
> http://www.banksandtaylor.com/dragonslayer.html
>
> - M
>
>
> On 6 Feb 2013, at 17:43, Sanne Grinovero  wrote:
>
>> Delirium Tremens
>>
>> very appropriate :-D
>>
>> On 6 February 2013 17:17, Mircea Markus  wrote:
>>> Following the tradition, please bring your suggestion of beer-code
>>> name for the new Infinispan release. Then we'll vote.
>>> Mine is  Guinness :-)
>>>
>>> Cheers,
>>> --
>>> Mircea Markus
>>> Infinispan lead (www.infinispan.org)
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> infinispan-dev mailing list
>>> infinispan-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> ___
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> ma...@jboss.org
> twitter.com/maniksurtani
>
> Platform Architect, JBoss Data Grid
> http://red.ht/data-grid
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Threadpools in a large cluster

[Pedro Ruivo]

Hi all,

Recently I came up with a solution that can help with the thread pool 
problem motivated by the following:


In one of the first implementation of Total Order based commit protocol 
(TO), I had the requirement to move the PrepareCommand to another thread 
pool. In resume, the TO protocol delivers the PrepareCommand in a 
deterministic order in all the nodes, by a single deliver thread. To 
ensure consistency, if it delivers two conflicting transactions, the 
second transaction must wait until the first transaction finishes. 
However, blocking single deliver thread is not a good solution, because 
no more transaction can be validated, even if they don't conflict, while 
the thread is blocked.


So, after creating a dependency graph (i.e. the second transaction knows 
that it must wait for the first transaction to finish) I move the 
PrepareCommand to another thread pool. Initially, I implemented a new 
command, called PrepareResponseCommand, that sends back the reply of the 
PrepareCommand. This solution has one disadvantage: I had to implement 
an ack collector in ISPN, while JGroups already offers me that with a 
synchronous communication.


Recently (2 or 3 months ago) I implemented a simple modification in 
JGroups. In a more generic approach, it allows other threads to reply to 
a RPC request (such as the PrepareCommand). In the previous scenario, I 
replaced the PrepareResponseCommand and the ack collector implementation 
with a synchronous RPC invocation. I've used this solution in other 
issues in the Cloud-TM's ISPN fork.


This solution is quite simple to implement and may help you to move the 
commands to ISPN internal thread pools. The modifications I've made are 
the following:


1) I added a new interface (see [1]) that is sent to the application 
instead of the Message object (see [4]). This interface contains the 
Message and it has a method to allow the application send the reply to 
that particular request.
2) I added a new object in [4] with the meaning: this return value is 
not the reply to the RPC request. This is the returned value that I 
return when I want to release the thread, because ISPN should return 
some object in the handle() method. Of course, I know that ISPN will 
invoke the sendReply() in some other place, otherwise, I will get a 
TimeoutException in the sender side.
3) Also I've changed the RequestCorrelator implementation to support the 
previous modifications (see [2] and [3])


In the Cloud-TM's ISPN fork I added a reference in the 
BaseCacheRpcCommand to [1] and added the method sendReply() [5]. In 
addition, I have the following uses cases working perfectly with this:


1) Total Order

The scenario described in the beginning. The ParallelTotalOrderManager 
returns the DO_NOT_REPLY object when it receives a remote PrepareCommand 
(see [6] line 77). When the PrepareCommand is finally processed by the 
rest of the interceptor chain, it invokes the PreapreCommand.sendReply() 
(see [6] line 230).


2) GMU remote get

GMU ensures SERIALIZABLE Isolation Level and the remote gets must ensure 
that the node that is processing the request has a minimum version 
available to ensure data consistency. The problem in ours initial 
implementation in large cluster, is the number of remote gets are very 
high and all the OOB are being blocked because of this condition.


Same thing I've done with the ClusteredRemoteGet as you can in see [7], 
line 93 and 105.


3) GMU CommitCommand

In GMU, the CommitCommand cannot be processed by any order. If T1 is 
serialized before T2, the commit command of T1 must be processed before 
the commit command of T2, even if the transactions do not have 
conflicts. This generates the same problem above and the same solution 
was adopted.


I know that you have discussed some solutions and I would like to know 
what it is your opinion about what I've described.


If you have questions, please let me know.

Cheers,
Pedro

[1] 
https://github.com/pruivo/JGroups/blob/t_cloudtm/src/org/jgroups/blocks/MessageRequest.java 

[2] 
https://github.com/pruivo/JGroups/blob/t_cloudtm/src/org/jgroups/blocks/RequestCorrelator.java#L463 

[3] 
https://github.com/pruivo/JGroups/blob/t_cloudtm/src/org/jgroups/blocks/RequestCorrelator.java#L495 

[4] 
https://github.com/pruivo/JGroups/blob/t_cloudtm/src/org/jgroups/blocks/RequestHandler.java 

[5] 
https://github.com/pruivo/infinispan/blob/cloudtm_v1/core/src/main/java/org/infinispan/commands/remote/BaseRpcCommand.java#L75 

Re: [infinispan-dev] Codename for Infinispan 5.3.0

[Erik Salter]

Being an American from Pennsylvania, it is state law that I suggest
Yuengling (despite the fact I don't drink)

-Original Message-
From: infinispan-dev-boun...@lists.jboss.org
[mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of Manik Surtani
Sent: Wednesday, February 06, 2013 12:47 PM
To: infinispan -Dev List
Subject: Re: [infinispan-dev] Codename for Infinispan 5.3.0

5.2.0 is Delirium.

https://github.com/infinispan/infinispan/blob/5.2.x/core/src/main/java/org/i
nfinispan/Version.java#L45

My vote - Dragonslayer

http://www.banksandtaylor.com/dragonslayer.html

- M


On 6 Feb 2013, at 17:43, Sanne Grinovero  wrote:

> Delirium Tremens
> 
> very appropriate :-D
> 
> On 6 February 2013 17:17, Mircea Markus  wrote:
>> Following the tradition, please bring your suggestion of beer-code 
>> name for the new Infinispan release. Then we'll vote.
>> Mine is  Guinness :-)
>> 
>> Cheers,
>> --
>> Mircea Markus
>> Infinispan lead (www.infinispan.org)
>> 
>> 
>> 
>> 
>> 
>> ___
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
ma...@jboss.org
twitter.com/maniksurtani

Platform Architect, JBoss Data Grid
http://red.ht/data-grid


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Codename for Infinispan 5.3.0

[Manik Surtani]

On 6 Feb 2013, at 18:02, Bela Ban  wrote:

> - Bug Light :-)

ROFL

--
Manik Surtani
ma...@jboss.org
twitter.com/maniksurtani

Platform Architect, JBoss Data Grid
http://red.ht/data-grid

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Codename for Infinispan 5.3.0

[Thomas Fromm]

Tas - http://www.ratebeer.com/beer/268erna-hora-tas-10o/19240/
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Codename for Infinispan 5.3.0

[Bela Ban]

- Corona (with lemon)
- Boddington's
- Bug Light :-)

On 2/6/13 5:17 PM, Mircea Markus wrote:
> Following the tradition, please bring your suggestion of beer-code 
> name for the new Infinispan release. Then we'll vote.
> Mine is  Guinness :-)
>
> Cheers,
> -- 
> Mircea Markus
> Infinispan lead (www.infinispan.org )
>
>
>
>
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Codename for Infinispan 5.3.0

[Sanne Grinovero]

Tactical Nuclear Penguin

Love the name :-)

On 6 February 2013 18:54, Jeff Ramsdale  wrote:
> I'll offer "Old Chub": http://www.oskarblues.com/the-brews/old-chub
>
> or for something a bit more out there, "Marooned on Hog Island":
> http://21st-amendment.com/beers/marooned-on-hog-island/
>
> -j
>
>
> On Wed, Feb 6, 2013 at 8:17 AM, Mircea Markus  wrote:
>>
>> Following the tradition, please bring your suggestion of beer-code name
>> for the new Infinispan release. Then we'll vote.
>> Mine is  Guinness :-)
>>
>> Cheers,
>> --
>> Mircea Markus
>> Infinispan lead (www.infinispan.org)
>>
>>
>>
>>
>>
>> ___
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Codename for Infinispan 5.3.0

[Jeff Ramsdale]

I'll offer "Old Chub": http://www.oskarblues.com/the-brews/old-chub

or for something a bit more out there, "Marooned on Hog Island":
http://21st-amendment.com/beers/marooned-on-hog-island/

-j


On Wed, Feb 6, 2013 at 8:17 AM, Mircea Markus  wrote:

> Following the tradition, please bring your suggestion of beer-code name
> for the new Infinispan release. Then we'll vote.
> Mine is  Guinness :-)
>
> Cheers,
> --
> Mircea Markus
> Infinispan lead (www.infinispan.org)
>
>
>
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

[infinispan-dev] Adding JSR-107 support for invokeEntryProcessor

[Galder Zamarreño]

Hi all,

We're meant to implement this method in JSR-107:
https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cache/Cache.java#L510

The interesting bit comes in the javadoc of EntryProcessor: 
https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cache/Cache.java#L510

To be more precise:

" * Allows execution of code which may mutate a cache entry with exclusive
 * access (including reads) to that entry.
 * 
 * Any mutations will not take effect till after the processor has 
completed; if an exception
 * thrown inside the processor, the exception will be returned wrapped in 
an 
 * ExecutionException.  No changes will be made to the cache.
 * 
 * This enables a way to perform compound operations without transactions
 * involving a cache entry atomically. Such operations may include 
mutations."

Having quickly glanced, there's several things that need addressing from 
Infinispan internals perspective:

1. Implies that we need to be able to lock a key without a transaction, 
something we don't currently support.

2. We need an unlock()

3. Requires exclusive access, even for read operations. Our lock() 
implementation still allows read operations.

These are fairly substantial changes (I'm planning to add them as subtasks to 
https://issues.jboss.org/browse/ISPN-2639) particularly 1) and 3), and so 
wanted to share some thoughts:

For 1 and 2, the easiest way I can think of doing this is by having a new 
LockingInterceptor that is similar to NonTransactionalLockingInterceptor, but 
unlocks only when unlock is called (as opposed to after each operation 
finishes).

For 3, we'd either need to add a new lock() method that supports locking 
read+write, or change lock() behaivour to also lock reads. The latter could 
break old clients, so I'd go for a new lock method, i.e. lockExclusively(). 
Again, to support this, a new different NonTransactionalLockingInterceptor is 
needed so that locks are acquired on read operations as well.

Finally, any new configurations could be avoided at this stage by simply having 
the JSR-107 adapter inject the right locking interceptor. IOW, if you use 
JSR-107, we'll swap NonTransactionalLockingInterceptor for 
JSR107FriendlyNonTransactionalLockingInterceptor.

Before I get started with this, I wanted to get the thoughts/opinions of the 
list.

Cheers,
--
Galder Zamarreño
gal...@redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Codename for Infinispan 5.3.0

[Manik Surtani]

5.2.0 is Delirium.

https://github.com/infinispan/infinispan/blob/5.2.x/core/src/main/java/org/infinispan/Version.java#L45

My vote - Dragonslayer

http://www.banksandtaylor.com/dragonslayer.html

- M


On 6 Feb 2013, at 17:43, Sanne Grinovero  wrote:

> Delirium Tremens
> 
> very appropriate :-D
> 
> On 6 February 2013 17:17, Mircea Markus  wrote:
>> Following the tradition, please bring your suggestion of beer-code name for
>> the new Infinispan release. Then we'll vote.
>> Mine is  Guinness :-)
>> 
>> Cheers,
>> --
>> Mircea Markus
>> Infinispan lead (www.infinispan.org)
>> 
>> 
>> 
>> 
>> 
>> ___
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
ma...@jboss.org
twitter.com/maniksurtani

Platform Architect, JBoss Data Grid
http://red.ht/data-grid


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Codename for Infinispan 5.3.0

[Sanne Grinovero]

Delirium Tremens

very appropriate :-D

On 6 February 2013 17:17, Mircea Markus  wrote:
> Following the tradition, please bring your suggestion of beer-code name for
> the new Infinispan release. Then we'll vote.
> Mine is  Guinness :-)
>
> Cheers,
> --
> Mircea Markus
> Infinispan lead (www.infinispan.org)
>
>
>
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

[infinispan-dev] Codename for Infinispan 5.3.0

[Mircea Markus]

Following the tradition, please bring your suggestion of beer-code name for the 
new Infinispan release. Then we'll vote.
Mine is  Guinness :-)

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)




___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

[infinispan-dev] UNICAST / UNICAST2 connection reaping

[Bela Ban]

Connection reaping may lead to message loss in UNICAST{2}. Until I've 
fixed [1], could you disable connection reaping ? Instructions are in [1].


[1] https://issues.jboss.org/browse/JGRP-1586

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] scala code in Infinispan

[Manik Surtani]

On 6 Feb 2013, at 14:58, Mircea Markus  wrote:

> On 6 Feb 2013, at 15:37, Galder Zamarreño wrote:
> I don't think that encouraging scala code is good purely for maintenance 
> reasons. If there's a choice, it should be java. Not saying that learning 
> a new language is not cool - but in practice people are a bit put off by 
> maintaining Scala code. Its not only about what the writer of the code 
> prefers as a language: it's more important what the maintainers of the 
> code 
> will has to work with.
 
 Would such maintainers also be put off by new language features (lambdas) 
 in Java 8 when we (eventually) baseline to it?  :-)
>>> It's really NOT the same thing: any decent java programmer keeps up with 
>>> all the enhancements in Java. 
>>> What I might not want to - as an ISPN programmer - is to keep up with the 
>>> language enhancements in Scala. And I might need to do that because of 
>>> Scala language enhancements used in ISPN.
>> 
>> ^ I wonder whether C programmers thought the same way 20 years ago.
> Personally I don't believe Scala is the next big thing as it doesn't have a 
> "killer" feature, e.g. OOP from C -> C++ or GC from C++ -> Java. 

That's 20/20 hindsight.  Lots of C developers said OOP was bullish*t when C++ 
came about, and even today some C++ folks argue than GC is for losers.  :)  

As Alan said, I for one look forward to writing all my code in JavaScript but 
until that day there is a lot of innovation we ought to embrace.  Java's shown 
itself to be slow to grow and evolve.  Oracle's acquisition of Sun has sped 
things up a lot, but it still is behind the curve.  There's a good reason why 
Ruby, Python, Erlang and Scala are gaining popularity.  If you've ever spent 
any time writing extensive code in any of these platforms you'd understand why.

- M

--
Manik Surtani
ma...@jboss.org
twitter.com/maniksurtani

Platform Architect, JBoss Data Grid
http://red.ht/data-grid

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] scala code in Infinispan

[Galder Zamarreño]

On Feb 6, 2013, at 3:58 PM, Mircea Markus  wrote:

> On 6 Feb 2013, at 15:37, Galder Zamarreño wrote:
> I don't think that encouraging scala code is good purely for maintenance 
> reasons. If there's a choice, it should be java. Not saying that learning 
> a new language is not cool - but in practice people are a bit put off by 
> maintaining Scala code. Its not only about what the writer of the code 
> prefers as a language: it's more important what the maintainers of the 
> code 
> will has to work with.
 
 Would such maintainers also be put off by new language features (lambdas) 
 in Java 8 when we (eventually) baseline to it?  :-)
>>> It's really NOT the same thing: any decent java programmer keeps up with 
>>> all the enhancements in Java. 
>>> What I might not want to - as an ISPN programmer - is to keep up with the 
>>> language enhancements in Scala. And I might need to do that because of 
>>> Scala language enhancements used in ISPN.
>> 
>> ^ I wonder whether C programmers thought the same way 20 years ago.
> Personally I don't believe Scala is the next big thing as it doesn't have a 
> "killer" feature, e.g. OOP from C -> C++ or GC from C++ -> Java. 

Scala opened my eyes to functional programming.

Whether that's a killer feature or not is debatable because functional 
programming has been around for tons of years, even probably more than OOP. 

Howver, from a Java developer perspective, I've seen no other programming 
language that has done more to promote functional programming than Scala, and 
that to me is a killer feature.

I'm very glad functional programming is coming to Java, but I hope they don't 
mess it up like they did with generics.

Even then, the functional programming bits coming to Java are just a fraction 
of the rest cool stuff that's present in Scala. The best example of this I've 
found is this:
http://www.myexpospace.com/JavaOne2012/SessionFiles/CON3470_mp4_3470_001.mp4

It's a very funny video too :D

On a more serious note, this is probably one of those arguments where the best 
we can do is agree to disagree. I'm slightly dissapointed with the final 
decision you've made, but this is open source development and live goes on…

Cheers,

> 
> Cheers,
> -- 
> Mircea Markus
> Infinispan lead (www.infinispan.org)
> 
> 
> 
> 
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
gal...@redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] scala code in Infinispan

[Bela Ban]

On 2/6/13 3:58 PM, Mircea Markus wrote:
> On 6 Feb 2013, at 15:37, Galder Zamarreño wrote:
> I don't think that encouraging scala code is good purely for 
> maintenance reasons. If there's a choice, it should be java. Not 
> saying that learning a new language is not cool - but in practice 
> people are a bit put off by maintaining Scala code. Its not only 
> about what the writer of the code prefers as a language: it's more 
> important what the maintainers of the code
> will has to work with.

 Would such maintainers also be put off by new language features 
 (lambdas) in Java 8 when we (eventually) baseline to it?  :-)
>>> It's really NOT the same thing: any decent java programmer keeps up 
>>> with all the enhancements in Java.
>>> What I might not want to - as an ISPN programmer - is to keep up 
>>> with the language enhancements in Scala. And I might need to do that 
>>> because of Scala language enhancements used in ISPN.
>>
>> ^ I wonder whether C programmers thought the same way 20 years ago.
> Personally I don't believe Scala is the next big thing as it doesn't 
> have a "killer" feature, e.g. OOP from C -> C++ or GC from C++ -> Java.

+1000.

Let the flame war start (Galder with his lighter against us with flam 
throwers) :-)


-- 
Bela Ban, JGroups lead (http://www.jgroups.org)

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] scala code in Infinispan

[Mircea Markus]

On 6 Feb 2013, at 15:37, Galder Zamarreño wrote:
 I don't think that encouraging scala code is good purely for maintenance 
 reasons. If there's a choice, it should be java. Not saying that learning 
 a new language is not cool - but in practice people are a bit put off by 
 maintaining Scala code. Its not only about what the writer of the code 
 prefers as a language: it's more important what the maintainers of the 
 code 
 will has to work with.
>>> 
>>> Would such maintainers also be put off by new language features (lambdas) 
>>> in Java 8 when we (eventually) baseline to it?  :-)
>> It's really NOT the same thing: any decent java programmer keeps up with all 
>> the enhancements in Java. 
>> What I might not want to - as an ISPN programmer - is to keep up with the 
>> language enhancements in Scala. And I might need to do that because of Scala 
>> language enhancements used in ISPN.
> 
> ^ I wonder whether C programmers thought the same way 20 years ago.
Personally I don't believe Scala is the next big thing as it doesn't have a 
"killer" feature, e.g. OOP from C -> C++ or GC from C++ -> Java. 

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)




___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] scala code in Infinispan

[Alan Santos]

On Feb 6, 2013, at 9:37 AM, Galder Zamarreño  wrote:

> 
> On Jan 31, 2013, at 1:42 PM, Mircea Markus  wrote:
> 
>> 
>> On 31 Jan 2013, at 12:37, Manik Surtani wrote:
>> 
 I don't think that encouraging scala code is good purely for maintenance 
 reasons. If there's a choice, it should be java. Not saying that learning 
 a new language is not cool - but in practice people are a bit put off by 
 maintaining Scala code. Its not only about what the writer of the code 
 prefers as a language: it's more important what the maintainers of the 
 code 
 will has to work with.
>>> 
>>> Would such maintainers also be put off by new language features (lambdas) 
>>> in Java 8 when we (eventually) baseline to it?  :-)
>> It's really NOT the same thing: any decent java programmer keeps up with all 
>> the enhancements in Java. 
>> What I might not want to - as an ISPN programmer - is to keep up with the 
>> language enhancements in Scala. And I might need to do that because of Scala 
>> language enhancements used in ISPN.
> 
> ^ I wonder whether C programmers thought the same way 20 years ago.

20 years ago? I'm pretty sure Bela said this last week.

Besides, it's all JavaScript these days. Scala is old and busted ;)


-alan



___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] scala code in Infinispan

[Galder Zamarreño]

On Jan 31, 2013, at 1:42 PM, Mircea Markus  wrote:

> 
> On 31 Jan 2013, at 12:37, Manik Surtani wrote:
> 
>>> I don't think that encouraging scala code is good purely for maintenance 
>>> reasons. If there's a choice, it should be java. Not saying that learning a 
>>> new language is not cool - but in practice people are a bit put off by 
>>> maintaining Scala code. Its not only about what the writer of the code 
>>> prefers as a language: it's more important what the maintainers of the code 
>>> will has to work with.
>> 
>> Would such maintainers also be put off by new language features (lambdas) in 
>> Java 8 when we (eventually) baseline to it?  :-)
> It's really NOT the same thing: any decent java programmer keeps up with all 
> the enhancements in Java. 
> What I might not want to - as an ISPN programmer - is to keep up with the 
> language enhancements in Scala. And I might need to do that because of Scala 
> language enhancements used in ISPN.

^ I wonder whether C programmers thought the same way 20 years ago.

Cheers,

> 
> Cheers,
> -- 
> Mircea Markus
> Infinispan lead (www.infinispan.org)
> 
> 
> 
> 
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
gal...@redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] scala code in Infinispan

[Galder Zamarreño]

Hi,

On Jan 31, 2013, at 12:45 PM, Mircea Markus  wrote:

> Hi,
> 
> 
> The REST module is written in Scala (both main + tests). We have some *test* 
> contributions written in Java (thanks  mlinhard).
> There was an IRC discussion on whether it's worth migrating the Java 
> contribution to Scala code or not. 
> 
> Pros for migrating the contribution from Java to Scala:
> - the REST module is written in Scala. Contributing these tests in Java would 
> make the module bi-lingual, potentially confusing future contributors
> - even though this is not the case with this particular contribution, there 
> might be code duplications between the scala test suite and java test suite.
> 
> Cons for migrating the contribution from Java to Scala:
> - there are contributors that are not familiar with Scala or are more 
> proficient with Java(such as mlinhard). Forcing them to contribute in a 
> language they are not familiar with would put them off
> - my general feeling over time was that people (including me) are not very 
> enthusiastic about debugging and extending Scala code. So IMO if there's a 
> choice between scala and java  (in the scope of the scala modules) we should 
> stick to Java wherever possible (such as this contribution). 
> 
> This email is not about the migration of scala code to java, but about the 
> very specific contribution described above (even thought the mix of 
> scala+java code in ISPN is a a very interesting topic by itself). 

My preference is for Scala projects to keep all code in Scala unless there's a 
major force (i.e. lack of equivalent enums in Scala that can be injected into).

If we focus on this specific case, unless there's a huge rush to integrate the 
test, this is a chance for the contributor (Michal) to get familiar with 
another programming language, which I think is a really good thing. 

Cheers,

> 
> Cheers,
> -- 
> Mircea Markus
> Infinispan lead (www.infinispan.org)
> 
> 
> 
> 
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
gal...@redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev