Branch 4.1.x freeze
by Galder Zamarreño
Please note that 4.1.x branch is now frozen ahead of the 4.1.0.CR1 release, so please refrain from making any commits to this branch without contacting me.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
16 years, 2 months
log4j.jar in all distro
by Galder Zamarreño
At least Infinispan -all.zip distro does not include a log4j jar in the root lib/ directory.
This means that by default it logs using JDK logging. However, we ship an etc/log4j.xml and it might not be obvious to people that they need to bring in log4j.jar to see changes being made to etc/log4j.xml having an effect.
So, I'd propose to include a log4j jar in the root lib/ directory.
Any objections to that?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
16 years, 2 months
porting from 4.1.x to trunk
by Mircea Markus
Hi,
I've just finished merging everything from 4.1.x to trunk, so trunk does contain latest and greatest from 4.1.x branch(r1875 through r1949)
Few thoughts on porting from 4.1.x and trunk:
- right now we use two approaches: one is to port each change in two places or to do a single merge/port before a release to contain all changes.
As per today's experience this doesn't work: Manik wanted to check into trunk a fix that depends on some code of mine, not yet ported: bang!
Both options have pros and cons.
My option is for doing larger grained merges, and here is why:
- simpler development process. With the former one need to do this additional work for each task:
- svn update on trunk
- copy (or svn merge) from 4.1.x to trunk
- mvn test on trunk, on the affected modules
- commit
Perhaps not a lot, but this needs to be done (virtually) on each commit. Otherwise people that rely on the changes will have problems while migrating theirs.
- a single SVN history (at the moment there are two of them).
The main cons is the conflict resolution. The longer you delay the integration, the more difficult it is to solve conflicts.
I don't think this is such a big issue: our code is quite clean, no big classes, no large methods, very modular project structure. We also have a test suite to run, which can give us confidence on the result of the merge.
I volunteer to take care of the merges for the next few releases. I'll clearly track down the time spent doing this, and we can have a clear image on what that would mean.
If it doesn't work we can always use the other approach (it would work though :) )
Wdyt?
Cheers,
Mircea
16 years, 2 months
ISPN-200
by Israel Lacerra
Manik,
About the "map" part of the map/reduce of ISPN-200.
Looking in the code, my intention is(briefly) create a ReplicableCommand in
CacheQueryImpl and then use RpcManager to make the query on all nodes.
But ISPN-200 depends on ISPN-39, right? This dependecy is about the map
part? The idea behind ISPN-39 is to migrate a computation to other nodes?
Like a "continuation"? And then ISPN-200 will use this api to make the query
on all nodes?
thanks!
Israel
16 years, 2 months
DataGrid Profile in JBoss AS
by Manik Surtani
On 29 Jun 2010, at 17:15, Brian Stansberry wrote:
> On 06/29/2010 09:29 AM, Manik Surtani wrote:
>>
>> On 29 Jun 2010, at 02:35, Brian Stansberry wrote:
>>
>>
<SNIP />
>>
>> You are correct in that it is to do with a datagrid profile for EAP. Or more specifically, something for AS (5.x?)
>
> Community AS 5.x is dead. There isn't even a branch for it (Jason deleted it to prevent people doing new dev on it.)
>
>> which would then also be tested on EAP 5.1,
>
> I expect this will first see the light of day via the EAP 5.1 branch. (Maybe not; see below.) That seems bizarre, but that's the way things work.
I was actually expecting this to be built as a module in Infinispan's source tree, the deliverable being a ZIP file that contains a "datagrid" directory and all the necessary elements that can be run as a profile in AS/EAP 5.1. Considering that most of the work involved would be XML config files (MC beans) and perhaps an integration class or two, I don't see the need for it to affect the AS source tree (at least not in it's current "tech preview" state).
>> and hopefully should work with minimal tweaking on AS 6.x as well. I am assuming the bulk of the work required would be closely related to the MC though, since the profile would have to configure and launch Infinispan instances and the various server endpoints as needed, via the MC.
>
> Paul has worked out the details of deploying a CacheManager (a set of them actually) in AS 6. Those will be what the standard AS clustering services will use. What's involved with setting up the server endpoints?
I was hoping to target AS/EAP 5.x first and then move on to 6, but FWIW any such profile for 6 should then make use of Paul's work in deploying a CacheManager. In the case of HotRod and Memcached, setting up an endpoint involves selecting the appropriate ProtocolServer implementation
http://fisheye.jboss.org/browse/Infinispan/trunk/server/core/src/main/sca...
and calling start() on it with the CacheManager to be used.
The REST endpoint is a little more tricky as it is a WAR file that Infinispan generates that would need to be deployed in a servlet container. The current WAR file creates its own CacheManager but we can change this to look up a CacheManager from elsewhere if configured to do so (perhaps via servlet or system properties).
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
16 years, 2 months
Single jar zip file, what's your thoughts on it?
by galder＠redhat.com
Hi,
Re: http://community.jboss.org/message/548002#548002
This is the 2nd time I've seen people having issues with the single jar zip file. What's the aim of it?
People using it have generally been trying to simply get started with core Infinispan jar and its dependencies, nothing else. When they look at the single jar and all the dependencies in lib/, they seem quite baffled and have issues as in the case above.
I think -bin.zip and -all.zip should be enough.
Maybe we should create a poll on this?
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
16 years, 2 months
Re: [infinispan-dev] Codename for 5.0
by galder＠jboss.org
My nomination: Pagoa
- Type of tree in Basque
- Name of a Basque beer
----- "Manik Surtani" <manik(a)jboss.org> wrote:
> As we march on with Infinispan releases, we need a new codename for
> 5.0. The big new features in 5.0 include a JPA-like API and natural
> language querying.
>
> Infinispan 4.0 was codenamed "Starobrno" and 4.1 is "Radegast" ...
> what will 5.0 be?
>
> Some suggestions from the last round of naming are:
>
> * Macunaima
> * Drak
>
> Any others? Once we have a list of nominations I'll set up a poll for
> people to vote. :)
>
> Cheers
> Manik
> --
> Manik Surtani
> manik(a)jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
16 years, 2 months
