http://www.couchbase.com/issues This file is an XML representation of an issue en-us 5.2.4 845 26-12-2012 http://www.couchbase.com/issues/browse/JCBC-189 Couchbase Java Client We&#39;re seeing really strange timeout issues which seem to affect only this specific cluster and only in terms of views. We&#39;ve re-installed this cluster time and time again, and we&#39;ve had similar configurations run successfully as well. <br/> <br/> More details in comment.. JCBC-189

Views having odd timeout issues on some clusters

Bug Major In Progress Unresolved Public Michael Nitschinger Mark Nunberg Tue, 18 Dec 2012 21:44:37 -0600 Sat, 11 May 2013 13:28:13 -0500 1.1.0 1.1.6 library 0 0 Just try to do this with a simple java script (i.e. connect and query the view) This issue persists when the view retrieval is ran from standalone java program as well. <br/> I tried this on both the VMs - 10.3.3.203, 10.3.3.209. Its working fine for server deployed on localhost. Michael: found out today that this is a large issue for SDKQE. Can you have a quick look at this in the next day? You may find the underlying issue. Please pass me the script as commented and then (or if you can&#39;t) please assign it back to me! Thanks According to the posted logs, it looks like debugging was not turned on. Can you please run this again with debugging turned on? To get the full logs to STDOUT, use this before initializing the CouchbaseClient in The App: <br/> <br/> &#xA0; &#xA0; &#xA0; // Tell spy to use the SunLogger <br/> &nbsp;&#xA0; &#xA0; &#xA0; &#xA0;Properties systemProperties = System.getProperties(); <br/> &nbsp;&#xA0; &#xA0; &#xA0; &#xA0;systemProperties.put(&quot;net.spy.log.LoggerImpl&quot;, &quot;net.spy.memcached.compat.log.SunLogger&quot;); <br/> &nbsp;&#xA0; &#xA0; &#xA0; &#xA0;System.setProperties(systemProperties); <br/> <br/> &nbsp;&#xA0; &#xA0; &#xA0; &#xA0;Logger.getLogger(&quot;com.couchbase.client&quot;).setLevel(Level.FINEST); <br/> <br/> &nbsp;&#xA0; &#xA0; &#xA0; &#xA0;//get the top Logger <br/> &nbsp;&#xA0; &#xA0; &#xA0; &#xA0;Logger topLogger = java.util.logging.Logger.getLogger(&quot;&quot;); <br/> <br/> &nbsp;&#xA0; &#xA0; &#xA0; &#xA0;// Handler for console (reuse it if it already exists) <br/> &nbsp;&#xA0; &#xA0; &#xA0; &#xA0;Handler consoleHandler = null; <br/> &nbsp;&#xA0; &#xA0; &#xA0; &#xA0;//see if there is already a console handler <br/> &nbsp;&#xA0; &#xA0; &#xA0; &#xA0;for (Handler handler : topLogger.getHandlers()) { <br/> &nbsp;&#xA0; &#xA0; &#xA0; &#xA0; &#xA0; &#xA0;if (handler instanceof ConsoleHandler) { <br/> &nbsp;&#xA0; &#xA0; &#xA0; &#xA0; &#xA0; &#xA0; &#xA0; &#xA0;//found the console handler <br/> &nbsp;&#xA0; &#xA0; &#xA0; &#xA0; &#xA0; &#xA0; &#xA0; &#xA0;consoleHandler = handler; <br/> &nbsp;&#xA0; &#xA0; &#xA0; &#xA0; &#xA0; &#xA0; &#xA0; &#xA0;break; <br/> &nbsp;&#xA0; &#xA0; &#xA0; &#xA0; &#xA0; &#xA0;} <br/> &nbsp;&#xA0; &#xA0; &#xA0; &#xA0;} <br/> <br/> &nbsp;&#xA0; &#xA0; &#xA0; &#xA0;if (consoleHandler == null) { <br/> &nbsp;&#xA0; &#xA0; &#xA0; &#xA0; &#xA0; &#xA0;//there was no console handler found, create a new one <br/> &nbsp;&#xA0; &#xA0; &#xA0; &#xA0; &#xA0; &#xA0;consoleHandler = new ConsoleHandler(); <br/> &nbsp;&#xA0; &#xA0; &#xA0; &#xA0; &#xA0; &#xA0;topLogger.addHandler(consoleHandler); <br/> &nbsp;&#xA0; &#xA0; &#xA0; &#xA0;} <br/> <br/> &nbsp;&#xA0; &#xA0; &#xA0; &#xA0;//set the console handler to fine: <br/> &nbsp;&#xA0; &#xA0; &#xA0; &#xA0;consoleHandler.setLevel(java.util.logging.Level.FINEST); <br/> <br/> <br/> Would be great if we can get all the output so we can investigate where the timeouts come from. I&#39;m sure with a debug log it will be much easier. Thanks! So this bug isn&#39;t such an &quot;unknown&quot; anymore, and has exposed itself in 1.1.0 as well as 1.1.1 and isn&#39;t limited to particular clusters - (it just seems that some clusters are more likely than others to trigger this bug). <br/> <br/> However this still needs a lot of care and analysis This is &quot;kinda&quot; blocker. Dependency MB-7661 JCBC-176 Rank 8575