Re: [infinispan-dev] Partial state transfer

[Bela Ban]

On 6/20/11 10:02 PM, Manik Surtani wrote:
> 5.1 is possible, 5.0 would be very tough.


Fine with me then; this gives me more time for 3.0


> What are the implications for our current implementation on 5.0 though?  
> State going missing?

No, Infinispan 5.0 uses JGroups 2.12.x, which still has partial state.

-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Issue posted for JBoss Logging and slf4j

[David M. Lloyd]

Due to the lack of a logging backend JAR, I am assuming that you are 
using java.util.logging for your logging backend.  There is nothing in 
JBoss Logging which handles appenders or handlers or logs messages in a 
loop of any kind; thus I think the most likely situation is that there 
are multiple log backends being configured at a JUL level.  Apart from 
the obvious "check the logging config file" [1] [2], it's quite possible 
that one or more JARs on the classpath are "helping" you by configuring 
additional log handlers on JUL's root logger programmatically.  I can 
tell you that neither JBoss Logging nor JBoss Marshalling does this, but 
beyond that I cannot say.

[1] 
http://download.oracle.com/javase/1.4.2/docs/guide/util/logging/overview.html
[2] http://www.crazysquirrel.com/computing/java/logging.jspx

On 06/20/2011 05:33 PM, Thomas P. Fuller wrote:
> David,
>
> "Leaving aside the fact that this is basically a "me too" post which
> actually describes a completely different problem - can you give some
> specifics?"
>
> Note that the author of the email asked specifically the following question:
>
> "Anybody else seeing a degradation in logging behavior?"
>
> If you're an expert with the internals of JBoss Logging, then fine for
> you to categorize this as a different problem, but I am not and from my
> angle one user has a problem with JBoss Logging and so do I. It is
> perfectly conceivable that they could be related which is why I took the
> time to respond to this specific question.
>
> Now, moving on to your queries:
>
> Here are the list of Jars that are in the classpath:
>
> hibernate-commons-annotations-3.2.0.Final.jar
> hibernate-infinispan-3.6.4-20110430.213848-9.jar
> hibernate-search-3.4.0.Final.jar
> infinispan-core.jar
> infinispan-query.jar
> jboss-logging-3.0.0.Beta5.jar
> jboss-marshalling-1.3.0.CR9.jar
> jboss-marshalling-river-1.3.0.CR9.jar
> jboss-transaction-api-1.0.1.GA.jar
> jcip-annotations-1.0.jar
> jgroups-2.12.0.Final.jar
> lucene-core-3.2.0.jar
> readme.txt
> rhq-pluginAnnotations-3.0.1.jar
>
> Re: "Are all messages duplicated, or just Infinispan's?"
>
> All messages are duplicated, and I just wrote a quite test application
> in Grails in complete isolation and the log messages only appear once.
>
> Regards,
>
> Tom
>
> 
> *From:* David M. Lloyd 
> *To:* infinispan-dev@lists.jboss.org
> *Sent:* Mon, 20 June, 2011 22:55:56
> *Subject:* Re: [infinispan-dev] Issue posted for JBoss Logging and slf4j
>
> On 06/20/2011 04:16 PM, Thomas P. Fuller wrote:
>  > I've had an issue upgrading to CR5 and I was just about to ask about
> this.
>  >
>  > Basically when running infinispan CR5 in Grails I am seeing log messages
>  > repeated two times whereas before upgrading I'd only see one.
>  >
>  > This is not a showstopper, but it's a bit annoying. I'm also not sure if
>  > this is an Infinispan problem or a Grails problem, however this wasn't
>  > an issue until recently, which is why I suspect that JBoss Logging is at
>  > fault here.
>
> Leaving aside the fact that this is basically a "me too" post which
> actually describes a completely different problem - can you give some
> specifics? Like, what JARs are on your classpath where you see the
> problem? Are all messages duplicated, or just Infinispan's? What
> logging backend are you trying to use, and how is it configured? What
> does the output actually look like, and what were you expecting?
>
> --
> - DML
> ___
> 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


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

Re: [infinispan-dev] Issue posted for JBoss Logging and slf4j

[Jeff Ramsdale]

Hi Dan,

I didn't see any failures building with 2.2.1 but the jar seemed to
behave differently. In retrospect it's possible Eclipse was resolving
against a local project without APT running instead of against the
published artifact that contained the class. Wish I had more data, but
ultimately I'd rather use the published jars than my own anyway. Once
the blocking ISPN-1148 was resolved and new jar released I was able to
move back to the published artifacts.

Thanks for the feedback!

-jeff

On Mon, Jun 20, 2011 at 3:07 PM, Dan Berindei  wrote:
> Hi Jeff
>
> I'm building Infinispan with Maven 2.2.1 on Fedora 14 and it works fine.
> I haven't noticed ISPN-1177 before, but I do get the error from time
> to time when I build from IntelliJ, because the IntelliJ compiler
> doesn't do annotation processing (or at least I haven't been able to
> configure it properly).
> Then when you run 'mvn install' maven sees that the class is up to
> date and doesn't run annotation processing either. Running 'mvn clean
> install' usually sorts everything out.
>
> Dan
>
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Issue posted for JBoss Logging and slf4j

[Thomas P. Fuller]

David,

"Leaving aside the fact that this is basically a "me too" post which actually  
describes a completely different problem - can you give some specifics?"

Note that the author of the email asked specifically the following  question:

"Anybody else seeing a degradation in logging behavior?"

If you're an expert with the internals of JBoss Logging, then fine for you to 
categorize this as a different problem, but I am not and from my angle one user 
has a problem with JBoss Logging and so do I. It is perfectly conceivable that 
they could be related which is why I took the time to respond to this specific 
question.

Now, moving on to your queries:

Here are the list of Jars that are in the classpath:

hibernate-commons-annotations-3.2.0.Final.jar
hibernate-infinispan-3.6.4-20110430.213848-9.jar
hibernate-search-3.4.0.Final.jar
infinispan-core.jar
infinispan-query.jar
jboss-logging-3.0.0.Beta5.jar
jboss-marshalling-1.3.0.CR9.jar
jboss-marshalling-river-1.3.0.CR9.jar
jboss-transaction-api-1.0.1.GA.jar
jcip-annotations-1.0.jar
jgroups-2.12.0.Final.jar
lucene-core-3.2.0.jar
readme.txt
rhq-pluginAnnotations-3.0.1.jar

Re: "Are all messages duplicated, or just Infinispan's?"

All messages are duplicated, and I just wrote a quite test application in 
Grails 
in complete isolation and the log messages only appear once.

Regards,

Tom




From: David M. Lloyd 
To: infinispan-dev@lists.jboss.org
Sent: Mon, 20 June, 2011 22:55:56
Subject: Re: [infinispan-dev] Issue posted for JBoss Logging and slf4j

On 06/20/2011 04:16 PM, Thomas P. Fuller wrote:
> I've had an issue upgrading to CR5 and I was just about to ask about this.
>
> Basically when running infinispan CR5 in Grails I am seeing log messages
> repeated two times whereas before upgrading I'd only see one.
>
> This is not a showstopper, but it's a bit annoying. I'm also not sure if
> this is an Infinispan problem or a Grails problem, however this wasn't
> an issue until recently, which is why I suspect that JBoss Logging is at
> fault here.

Leaving aside the fact that this is basically a "me too" post which 
actually describes a completely different problem - can you give some 
specifics?  Like, what JARs are on your classpath where you see the 
problem?  Are all messages duplicated, or just Infinispan's?  What 
logging backend are you trying to use, and how is it configured?  What 
does the output actually look like, and what were you expecting?

-- 
- DML
___
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] Issue posted for JBoss Logging and slf4j

[Dan Berindei]

Hi Jeff


On Mon, Jun 20, 2011 at 10:48 AM, Jeff Ramsdale  wrote:
> I've posted https://issues.jboss.org/browse/JBLOGGING-65 to address an
> issue I've run into converting to Infinispan 5.0.0.CR5. The issue
> concerns the switch to JBoss Logging and its failure to support
> log4j-over-slf4j, a jar provided by slf4j to adapt log4j events and
> route them to slf4j.
>
> JBoss Logging doesn't detect that org.apache.log4j.LogManager is
> provided by the log4j-over-slf4j jar and selects the
> Log4jLoggerProvider instead of the Slf4jLoggerProvider.
>
> I still haven't nailed down what's going on with logging in Infinispan
> 5.0.0 but I'm not getting any logging output and have run into several
> issues. See https://issues.jboss.org/browse/ISPN-1177 as well (it
> seems Maven 3 is required to build Infinispan 5?). I have concerns
> that folks converting from 4.x will have issues as I have and wanted
> to raise a red flag before release. Anybody else seeing a degradation
> in logging behavior?
>

I'm building Infinispan with Maven 2.2.1 on Fedora 14 and it works fine.
I haven't noticed ISPN-1177 before, but I do get the error from time
to time when I build from IntelliJ, because the IntelliJ compiler
doesn't do annotation processing (or at least I haven't been able to
configure it properly).
Then when you run 'mvn install' maven sees that the class is up to
date and doesn't run annotation processing either. Running 'mvn clean
install' usually sorts everything out.

Dan


> -jeff
> ___
> 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] Issue posted for JBoss Logging and slf4j

[David M. Lloyd]

On 06/20/2011 04:16 PM, Thomas P. Fuller wrote:
> I've had an issue upgrading to CR5 and I was just about to ask about this.
>
> Basically when running infinispan CR5 in Grails I am seeing log messages
> repeated two times whereas before upgrading I'd only see one.
>
> This is not a showstopper, but it's a bit annoying. I'm also not sure if
> this is an Infinispan problem or a Grails problem, however this wasn't
> an issue until recently, which is why I suspect that JBoss Logging is at
> fault here.

Leaving aside the fact that this is basically a "me too" post which 
actually describes a completely different problem - can you give some 
specifics?  Like, what JARs are on your classpath where you see the 
problem?  Are all messages duplicated, or just Infinispan's?  What 
logging backend are you trying to use, and how is it configured?  What 
does the output actually look like, and what were you expecting?

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

Re: [infinispan-dev] Issue posted for JBoss Logging and slf4j

[Thomas P. Fuller]

I've had an issue upgrading to CR5 and I was just about to ask about this. 


Basically when running infinispan CR5 in Grails I am seeing log messages  
repeated two times whereas before upgrading I'd only see one.

This is not a showstopper, but it's a bit annoying. I'm also not sure if this 
is 
an Infinispan problem or a Grails problem, however this wasn't an issue until 
recently, which is why I suspect that JBoss Logging is at fault here.


Tom
   
Thomas P. Fuller,  MSc
Managing Director

Coherent Logic Limited
High Performance  Software Engineering

thomas.ful...@coherentlogic.com
IM:  thospfuller (Yahoo)

Registered in England, #05560634
 


145-157 St.  John Street
London, EC1V 4PY United Kingdom

work:   44.[0]207.788.7654
mobile:  44.[0]781.828.7465
 





From: Jeff Ramsdale 
To: infinispan -Dev List 
Sent: Mon, 20 June, 2011 8:48:47
Subject: [infinispan-dev] Issue posted for JBoss Logging and slf4j

I've posted https://issues.jboss.org/browse/JBLOGGING-65 to address an
issue I've run into converting to Infinispan 5.0.0.CR5. The issue
concerns the switch to JBoss Logging and its failure to support
log4j-over-slf4j, a jar provided by slf4j to adapt log4j events and
route them to slf4j.

JBoss Logging doesn't detect that org.apache.log4j.LogManager is
provided by the log4j-over-slf4j jar and selects the
Log4jLoggerProvider instead of the Slf4jLoggerProvider.

I still haven't nailed down what's going on with logging in Infinispan
5.0.0 but I'm not getting any logging output and have run into several
issues. See https://issues.jboss.org/browse/ISPN-1177 as well (it
seems Maven 3 is required to build Infinispan 5?). I have concerns
that folks converting from 4.x will have issues as I have and wanted
to raise a red flag before release. Anybody else seeing a degradation
in logging behavior?

-jeff
___
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] Alert from a failing test

[Sanne Grinovero]

2011/6/20 Manik Surtani :
> Oddly enough, I don't see any other tests exhibiting this behaviour.  Let me 
> know if you see it in more recent CI runs, and we'll investigate in detail.

In fact there are not many tests in core which verify a full stream is
received; but as in another thread I mentioned I was seeing the
following exception relatively often (it never caught my attention
some months ago)

Caused by: java.io.EOFException: The stream ended unexpectedly.
Please check whether the source of the stream encountered any issues
generating the stream.
at 
org.infinispan.marshall.VersionAwareMarshaller.objectFromObjectStream(VersionAwareMarshaller.java:193)
at 
org.infinispan.statetransfer.StateTransferManagerImpl.processCommitLog(StateTransferManagerImpl.java:218)
at 
org.infinispan.statetransfer.StateTransferManagerImpl.applyTransactionLog(StateTransferManagerImpl.java:245)
at 
org.infinispan.statetransfer.StateTransferManagerImpl.applyState(StateTransferManagerImpl.java:284)
... 27 more
Caused by: java.io.EOFException: Read past end of file
at 
org.jboss.marshalling.SimpleDataInput.eofOnRead(SimpleDataInput.java:126)
at 
org.jboss.marshalling.SimpleDataInput.readUnsignedByteDirect(SimpleDataInput.java:263)
at 
org.jboss.marshalling.SimpleDataInput.readUnsignedByte(SimpleDataInput.java:224)
at 
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at 
org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
at 
org.infinispan.marshall.jboss.GenericJBossMarshaller.objectFromObjectStream(GenericJBossMarshaller.java:191)
at 
org.infinispan.marshall.VersionAwareMarshaller.objectFromObjectStream(VersionAwareMarshaller.java:191)
... 30 more

This looks like a suspicious correlation to me, as I think the
reported errors are similar in nature.

Cheers,
Sanne



>
> On 18 Jun 2011, at 20:18, Sanne Grinovero wrote:
>
>> Hello all,
>> I'm not in state to fully debug the issue this week, but even though
>> this failure happens in the Lucene Directory it looks like it's
>> reporting an issue with Infinispan core:
>>
>> https://infinispan.ci.cloudbees.com/job/Infinispan-master-JDK6-tcp/90/org.infinispan$infinispan-lucene-directory/testReport/junit/org.infinispan.lucene/SimpleLuceneTest/org_infinispan_lucene_SimpleLuceneTest_testIndexWritingAndFinding/
>>
>> In this test we're writing to the index, and then asserting on the
>> expected state on both nodes, but while it is successful on the same
>> node as the writer, it fails with
>> "java.io.IOException: Read past EOF" on the second node.
>>
>> This exception can mean only one thing: the value, which is a
>> buffer[], was not completely transferred to the second node, which
>> seems quite critical as the caches are using sync.
>> I can't reproduce the error locally, but it's not the first time it is
>> reported by CI: builds 60, 62, 65 for example (and more) show the same
>> testcase fail in the same manner.
>>
>> Cheers,
>> Sanne
>> ___
>> 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
>
> Lead, Infinispan
> http://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

Re: [infinispan-dev] Alert from a failing test

[Manik Surtani]

Oddly enough, I don't see any other tests exhibiting this behaviour.  Let me 
know if you see it in more recent CI runs, and we'll investigate in detail.

On 18 Jun 2011, at 20:18, Sanne Grinovero wrote:

> Hello all,
> I'm not in state to fully debug the issue this week, but even though
> this failure happens in the Lucene Directory it looks like it's
> reporting an issue with Infinispan core:
> 
> https://infinispan.ci.cloudbees.com/job/Infinispan-master-JDK6-tcp/90/org.infinispan$infinispan-lucene-directory/testReport/junit/org.infinispan.lucene/SimpleLuceneTest/org_infinispan_lucene_SimpleLuceneTest_testIndexWritingAndFinding/
> 
> In this test we're writing to the index, and then asserting on the
> expected state on both nodes, but while it is successful on the same
> node as the writer, it fails with
> "java.io.IOException: Read past EOF" on the second node.
> 
> This exception can mean only one thing: the value, which is a
> buffer[], was not completely transferred to the second node, which
> seems quite critical as the caches are using sync.
> I can't reproduce the error locally, but it's not the first time it is
> reported by CI: builds 60, 62, 65 for example (and more) show the same
> testcase fail in the same manner.
> 
> Cheers,
> Sanne
> ___
> 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

Lead, Infinispan
http://www.infinispan.org




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

Re: [infinispan-dev] Partial state transfer in Infinispan

[Manik Surtani]

On 17 Jun 2011, at 13:49, Mircea Markus wrote:

> 
>> But yes, there is no reason why we can't replace this with RPC as per 
>> Distribution, however I think we do need a streaming solution - not just for 
>> replication but distribution as well.  As such I'd only want to re-implement 
>> this bit once, rather than a temp RPC based solution first.  So we need a 
>> mechanism to either:
> Now this might sound a bit too radical but do we really need REPLICATED mode?

Yes.  :-)  REPL is ideal for certain common usage patterns: read-heavy, small 
clusters (under 10 nodes), small overall data volume (fits in any single JVM's 
heap).  This gives fast reads since reads are always local, etc.

> This is not fully brewed, but if e.g. we set numOwners = Integer.MAX_INTEGER 
> the cluster is effectively in replicated mode, so can't we just drop the 
> REPLICATION entirely? This would reduce the code size significantly...

We could in theory achieve this as you suggest with numOwners = MAX_INTEGER, 
but internally we'd still be best off implementing this as we have right now.  
Saves on a lot of overhead (memory as well as processing) compared to a 
DIST-like setup with an unlimited number of data owners.

>> 
>> (1) open a separate TCP socket for the sake of streaming state, or
>> (2) reuse the sockets JGroups opens.
>> They both have their pros and cons.
>> 
>> (1) is more configuration, firewall setup, and a spiderweb of connections in 
>> a large grid
>> (2) would mean multiplexing with JGroups' use of the socket.
> Having our own sockets might cause an administration complications. Also 
> borrowing sockets from jgroups doesn't seems nice...I'm not a fan of either 
> solution really: I think this should be transport's responsibility and we 
> should enhance jgroups to offer the streaming service.

Yes, it would be implemented in our Transport abstraction, for sure.  So code 
wouldn't leak, but all the same there is no hard requirement that JGroups 
provides this (since it could be impl'd in JGroupsTransport).


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

Lead, Infinispan
http://www.infinispan.org



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

Re: [infinispan-dev] Partial state transfer

[Manik Surtani]

5.1 is possible, 5.0 would be very tough.

What are the implications for our current implementation on 5.0 though?  State 
going missing?

On 16 Jun 2011, at 17:56, Bela Ban wrote:

> Correct. Time frame would ideally be 5.0, but realistically it will 
> probably be 5.1. Is that feasible from a roadmap point of view ?
> 
> On 6/16/11 6:47 PM, Vladimir Blagojevic wrote:
>> In another words the essential problem is that digest and channel state
>> are per channel abstractions and they do not fit nicely with higher
>> level abstractions like substates? We use partial state transfer in
>> Infinispan and we need to address this.
>> 
>> What is the time frame here? 5.0 final release?
>> 
>> Vladimir
>> 
>> On 11-06-15 11:39 AM, Bela Ban wrote:
>>> I looked into adding partial state transfer back into JGroups, but found
>>> out that partial state transfer is fundamentally flawed, something I've
>>> always suspected ! (Regular state transfer is correct, and has always
>>> been correct).
>>> 
>>> - Say we have node A and B. B requests the state from A
>>> - There are partial states X and Y
>>> - Message M1 modifies X, M2 modifies Y
>>> 
>>> Here's what happens:
>>> 
>>> T1: A multicasts M1
>>> T2: A delivers M1, and changes X
>>> T3: B sends a GET_STATE("Y") request to A // partial state request
>>> for state Y
>>> T4: A multicasts M2
>>> T5: A delivers M2, changing Y
>>> T6: A receives the GET_STATE request, sends a SET_STATE response back
>>> including Y and the digest (including M1 and M2's seqnos)
>>> T7: B receives the SET_STATE response, sets its digest (includes now M1
>>> and M2) and state Y *BUT NOT* state X !
>>> T8: *** B receives M1, discards it because it is already in its digest
>>> ***
>>> T9: B receives M2, and also discards it
>>> 
>>> 
>>> At time T8, M1 (which would have changed state X) is discarded, because
>>> it is already in the digest sent with the SET_STATE response. Therefore
>>> state X is now incorrect, as M1 was never applied !
>>> 
>>> As a summary, if we get a number of updates to partial states, and don't
>>> receive all of them before requesting the partial state, the last update
>>> includes in the digest wins...
>>> 
>>> I'm a real idiot, as I've written this down before, in 2006: see [1] for
>>> details.
>>> 
>>> In a nutshell, [1] shows that partial state transfer doesn't work,
>>> unless virtual synchrony (FLUSH) is used.
>>> 
>>> So I propose Infinispan and JBoss AS look into how they can replace
>>> their use of partial state transfer. I suggest Infinispan uses the same
>>> approach already used for state transfer with mode=distribution.
>>> 
>>> Opinions ?
>>> 
>>> [1]
>>> https://github.com/belaban/JGroups/blob/master/doc/design/PartialStateTransfer.txt
>>> 
>>> 
>> 
> 
> -- 
> Bela Ban
> Lead JGroups / Clustering Team
> JBoss
> ___
> 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

Lead, Infinispan
http://www.infinispan.org




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

Re: [infinispan-dev] benchmarking transactions

[Mircea Markus]

On 20 Jun 2011, at 16:19, Mark Little wrote:
> But are you using JBossTS or DummyTransactionManager?
DummyTM. 
New results I'm about to publish are run with JBossTS configured with a 
VolatileStore.



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

[infinispan-dev] Issue posted for JBoss Logging and slf4j

[Jeff Ramsdale]

I've posted https://issues.jboss.org/browse/JBLOGGING-65 to address an
issue I've run into converting to Infinispan 5.0.0.CR5. The issue
concerns the switch to JBoss Logging and its failure to support
log4j-over-slf4j, a jar provided by slf4j to adapt log4j events and
route them to slf4j.

JBoss Logging doesn't detect that org.apache.log4j.LogManager is
provided by the log4j-over-slf4j jar and selects the
Log4jLoggerProvider instead of the Slf4jLoggerProvider.

I still haven't nailed down what's going on with logging in Infinispan
5.0.0 but I'm not getting any logging output and have run into several
issues. See https://issues.jboss.org/browse/ISPN-1177 as well (it
seems Maven 3 is required to build Infinispan 5?). I have concerns
that folks converting from 4.x will have issues as I have and wanted
to raise a red flag before release. Anybody else seeing a degradation
in logging behavior?

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