[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
Re: [infinispan-dev] Partial state transfer
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] Partial state transfer in Infinispan
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] 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
Re: [infinispan-dev] Issue posted for JBoss Logging and slf4j
Hi Jeff On Mon, Jun 20, 2011 at 10:48 AM, Jeff Ramsdale jeff.ramsd...@gmail.com 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, 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 david.ll...@redhat.com 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
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 dan.berin...@gmail.com 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
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 david.ll...@redhat.com *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 mailto: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
