I have been trying to add a new node to a cluster on 2.5.1 Enterprise. I have two buckets on a single node, and they've been working fine for a couple of months. After adding a second node to the cluster, I'm experiencing two major issues:
1) Rebalancing consistently fails. Sometimes it gets further than others (accordign to the graphical percentage calculator that pops up during rebalance), but always fails with this:
ns_vbucket_mover000
<0.1925.723> exited with {unexpected_exit,
{'EXIT',<0.1932.723>,
{badmatch,
[{'EXIT',
{{badmatch,{error,closed}},
{gen_server,call,
[<18986.2801.86>,had_backfill,infinity]}}}]}}}
ns_orchestrator002
Rebalance exited with reason {unexpected_exit,
{'EXIT',<0.1932.723>,
{badmatch,
[{'EXIT',
{{badmatch,{error,closed}},
{gen_server,call,
[<18986.2801.86>,had_backfill,infinity]}}}]}}}
Since encountering this error, I've also started experiencing random timeout errors when retrieving views. Not sure if they're related, but after a few months of uninterrupted service, the coincidence seems suspicious.
I've looked everywhere on couchbase error tracking system and also made an (unsuccessful) attempt to post an issue there.
FWIW, I upgraded couchbase to 3.0.3 and haven't seen this error since.
Related
I don't understand why I am getting a "run build" and "build failed" error when I have not added or deleted any code.
I tried the "invalidate cache/restart" as well as "rebuild project" but the error still occurs.
The first is below:
Unable to resolve dependency for
':app#debugAndroidTest/compileClasspath': Could not resolve
androidx.test.espresso:espresso-core:3.2.0.9
The second error is
Unable to resolve dependency for
':app#debugAndroidTest/compileClasspath': Could not resolve
androidx.test:monitor:1.2.0
.
These errors are occurring in the initial build as I am attempting to do my 1st class assignment. My accountability partner and I attempted to figure it out but he has a Mac (Maybe that's why he couldn't reproduce the errors) I cleared the cache, restarted the build several times. Updated Gradle. Doubled checked settings. etc.
I am at a loss for a resolution.
The problem was traced back to my machine not having enough RAM.
Meh, I'm a coding newbie this is all apart of the learning process as well as changing career fields.
Hi I have a web application runnig on the Aurelia CLI.
From what I’ve read in the documentation, the Aurelia CLI runs always “bundled” and never targeting directly source files. By running the “au run –watch” command, Aurelia “listens” to file changes and recreates the app-bundle.js automatically. Sample output from console:
Starting 'readProjectConfiguration'...
Finished 'readProjectConfiguration'
Starting 'processMarkup'...
Starting 'processCSS'...
Starting 'configureEnvironment'...
Finished 'configureEnvironment'
Starting 'buildJavaScript'...
Finished 'processCSS'
Finished 'processMarkup'
Finished 'buildJavaScript'
Starting 'writeBundles'...
Tracing views/references...
Writing app-bundle.js...
Finished 'writeBundles'
Starting 'reload'...
Finished 'reload'
This is cool, but in my case it leads to a poor developer experience. When I come to work in the morning, any change I make is readily updated in the app.bundle, but after working for some time, the “buildJavaScript” process (see console output) takes always longer to finish, after a few hours of work even up to 30-40 seconds! For me, working as a developer and having to test many small changes, this is extremely painful.
I tried (and still do) from time to time to stop the “au run –watch” command and re-execute it again, and initially it gets a bit better, but after some time the problem is there again.
My question would be: is there a workaround for that, or some way to speed this up or to have it served directly from the source files and not the bundled version, or maybe some other solution? Could this be due to a memory leak in Aurelia itself?
UPDATE:
Every once in a while it gets so slow that it actually crashes.
This is what I got today (and other few times) from the console:
==== Details ================================================
[1]: _tickCallback(aka _tickDomainCallback) [internal/process/next_tick.js:~108] [pc=000000C928AFCE81](this=000003B0DF48BE31 <a process with map 0000012166110B71>) {...
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
This is a late answer, but for future reference I think it's important to point out that since the more recent Aurelia CLI releases this problem has been fixed.
The performance issue, together with some major stability issues, have thoroughly discussed in GitHub #293: Error in buildTypeScript: A project cannot be used in two compilations at the same time.
Which means that if you update the Aurelia CLI to v0.30 or higher, you'll experience a significantly better performance and stability.
I've been experiencing a strange error while working on my Play Framework project. While my project is running, I will sometimes receive a ClassCastException, but the error is this:
ClassCastException occured : models.Person cannot be cast to models.Person
This occurs usually when I'm calling a find method such as:
Person p = Person.find("name=?","Joe").first();
If I restart the project, the problem goes away, but only temporarily. It makes testing my project a major pain. How do I fix this?
I've experienced this error while in Dev mode in Play, in two scenarios (as far as I can remember):
Modify an entity and try to recover values from cache that are objects of that entity class.
A compilation error while reloading the code of the page/application
In both scenarios fixing compilation errors or cleaning the cache solved the issue.
Not saying that those are the only possibilities, it may be that you are having some other issue.
This most likely occurs because you've somehow loaded the Person class under two different class loaders. When a class is loaded twice in two different class loaders it's effectively two distinct classes.
(Unfortunately, I can't tell you where/how you might have done this.)
(And it is a bit curious to have the problem pop up on the statement you list. Are you certain that's where it's occurring? Perhaps you should show the exception traceback.)
In my case, this is related to applying evolutions from the web interface. Someone raised a bug for this, but so far it hasn't received any attention from the dev team. There is a patch attached to the ticket, but I haven't tried it, so YMMV.
I'm using Northscale 1.0.0 and need a little help getting it to limp along for long enough to upgrade to the new version. I'm using C# and ASP.NET to work with it using the Enyim libraries. I currently suspect that the application does not have enough connections per the socketPool setting in my app.config. I also noted that the previous developer's code simply treats ANY exception from an attempted Get call to MemCache as if the item isn't in the cache, which (I believe) may be resulting in periodic spikes in calls to the database when the pool gets starved. We've been having oddball load spikes that don't seem to have any relation to server load. I suspect that he is not correctly managing the lifecycle on the connections to Northscale and that we are periodically experiencing starvation in the socket pool as a result, but I'm unable to prove it.
Is there a specific exception I should be looking for when I call the Get method to retrieve items from cache? I'm not really seeing much in the docs that gives me sufficient information on this. Anybody have any sample code on this? I'd even accept java or php code, as I think the .NET libraries were probably based on one of those anyway.
Any ideas?
Thanks,
Will
If you have made the connection correctly to the membase server(formerly Northscale) typically you only get an exception on 'get' when it's not a hit.
I have been using Netbeans 6.1 for a long time and my debugger has always been flawless. Somehow recently (within the last two weeks or so) my debugger stops at breakpoints but it either freezes most of the time or i can't find out the value of any variable, my local variables wont expand and my watches will sometimes show all nulls even for this.hashCode() or not even update at all and freeze.
When this happens i see the following netbeans exceptions
com.sun.jdi.InternalException: Unexpected JDWP Error: 502
at com.sun.tools.jdi.JDWPException.toJDIException(JDWPException.java:47)
at com.sun.tools.jdi.ObjectReferenceImpl.invokeMethod(ObjectReferenceImpl.java:379)
at org.netbeans.modules.debugger.jpda.expr.TreeEvaluator.invokeVirtual(TreeEvaluator.java:164)
at org.netbeans.modules.debugger.jpda.JPDADebuggerImpl.invokeMethod(JPDADebuggerImpl.java:844)
at org.netbeans.modules.debugger.jpda.models.AbstractObjectVariable.invokeMethod(AbstractObjectVariable.java:417)
at org.netbeans.modules.debugger.jpda.ui.models.JavaVariablesFilter.getChildren(JavaVariablesFilter.java:133)
at org.netbeans.modules.debugger.jpda.ui.models.VariablesTreeModelFilter.getChildren(VariablesTreeModelFilter.java:193)
at org.netbeans.spi.viewmodel.Models$CompoundTreeModel.getChildren(Models.java:628)
at org.netbeans.spi.viewmodel.Models$CompoundModel.getChildren(Models.java:2819)
at org.netbeans.modules.viewmodel.TreeModelNode$TreeModelChildren.evaluateLazily(TreeModelNode.java:701)
at org.netbeans.modules.viewmodel.TreeModelNode$LazyEvaluator.run(TreeModelNode.java:1124)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:561)
[catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:986)
com.sun.jdi.InternalException: Unexpected JDWP Error: 502
at com.sun.tools.jdi.JDWPException.toJDIException(JDWPException.java:47)
at com.sun.tools.jdi.ObjectReferenceImpl.invokeMethod(ObjectReferenceImpl.java:379)
at org.netbeans.modules.debugger.jpda.expr.TreeEvaluator.invokeVirtual(TreeEvaluator.java:164)
at org.netbeans.modules.debugger.jpda.JPDADebuggerImpl.invokeMethod(JPDADebuggerImpl.java:844)
at org.netbeans.modules.debugger.jpda.models.AbstractObjectVariable.getToStringValue(AbstractObjectVariable.java:315)
at org.netbeans.modules.debugger.jpda.models.AbstractObjectVariable.getToStringValue(AbstractObjectVariable.java:285)
at org.netbeans.modules.debugger.jpda.ui.models.VariablesNodeModel.getLimitedToString(VariablesNodeModel.java:316)
at org.netbeans.modules.debugger.jpda.ui.models.VariablesNodeModel.getShortDescriptionSynch(VariablesNodeModel.java:275)
at org.netbeans.modules.debugger.jpda.ui.models.VariablesNodeModel$1.run(VariablesNodeModel.java:233)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:561)
[catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:986)
Does anybody know how to fix or workaround this problem? I have googled this exception but can't find anything of value. The only thing i found is about running two different JVMs, one to debug and one to run the application (but this is not the case for me, both JVMs are the exact same version "1.4.2_03"). I am running into this issue at work so upgrading Java or my IDE is not an option, though it this was fixed in a newer version of the IDE i would still like to know that but most importantly I really need a fix or workaround for this. I have also not changed any settings in my project or NetBeans that i am aware of from the time my debugger was working to now.
Thanks
Append: I also got the following message
A com.sun.jdi.InternalException exception has occurred.
Please report this at http://www.netbeans.org/community/issues.html,
including a copy of your messages.log file as an attachment.
The messages.log file is located in your C:\Documents and Settings\default.netbeans\6.1\var\log folder.
And i have a copy of messages.log if anyone wants me to post it.
I also tried debugging with a different project that i haven't used in a while and it still failed in the same way.
I could really use some help on this one.
It's probably issue # 136461. If the software update(s) for 6.1 do not fix it, then you're probably out of luck. NB 6.1 is over 2 years old at this point.
I understand the desire to keep all developers on the same IDE release. A change to a .form file or a nbproject file can spoil an unwary developer's day.
However, can you install a personal copy of 6.9 and just use it for debugging? Keep the 6.1 around to verify everything before committing.