I have a never before seen problem with NodeDriver, when running a simple node driver program:
fun main(args: Array<String>) {
val rpcUsers = listOf(User("user1", "test", permissions = setOf("ALL")))
driver(DriverParameters(startNodesInProcess = true, waitForAllNodesToFinish = true)) {
startNode(providedName = CordaX500Name("PartyA", "London", "GB"), rpcUsers = rpcUsers).getOrThrow()
startNode(providedName = CordaX500Name("PartyB", "New York", "US"), rpcUsers = rpcUsers).getOrThrow()
}
}
When I run this in a new Kotlin template cordapp project, using Corda OS 4.1, it works fine.
However, when its run in our existing cordapp, it fails eventually with:
java.lang.IllegalStateException: Unable to start notaries. A required port might be bound already.
at net.corda.testing.node.internal.DriverDSLImpl.start(DriverDSLImpl.kt:373) ~[corda-node-driver-4.1.jar:?]
at net.corda.testing.node.internal.DriverDSLImplKt.genericDriver(DriverDSLImpl.kt:966) ~[corda-node-driver-4.1.jar:?]
at net.corda.testing.driver.Driver.driver(Driver.kt:190) ~[corda-node-driver-4.1.jar:?]
at io.bluebank.braid.server.CordaAndBraidStandaloneKt.main(CordaAndBraidStandalone.kt:48) ~[test-classes/:?]
Caused by: java.util.concurrent.TimeoutException
at java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1771) ~[?:1.8.0_212]
at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915) ~[?:1.8.0_212]
at net.corda.core.internal.concurrent.CordaFutureImpl.get(CordaFutureImpl.kt) ~[corda-core-4.1.jar:?]
at net.corda.core.internal.concurrent.CordaFutureImplKt.get(CordaFutureImpl.kt:172) ~[corda-core-4.1.jar:?]
at net.corda.core.utilities.KotlinUtilsKt.getOrThrow(KotlinUtils.kt:134) ~[corda-core-4.1.jar:?]
at net.corda.testing.node.internal.DriverDSLImpl.start(DriverDSLImpl.kt:369) ~[corda-node-driver-4.1.jar:?]
Debugging this, when I break point during whatever is blocking it, all threads are in a WAIT state, apart from one called SignalDispatcher which is RUNNING. None of the stacks are within Corda. However, some are in blocked within the Quasar stack.
Debugging further, I've found the line where the blocking behaviour happens: net.corda.node.services.rpc.ArtemisRpcBroker.kt:74
val serverConfiguration = RpcBrokerConfiguration(baseDirectory, maxMessageSize, jmxEnabled, addresses.primary, adminAddressOptional, sslOptions, useSsl, nodeConfiguration, shouldStartLocalShell)
Stepping into that constructor, Quasar takes over and appears to call ClassLoader.checkPackageAccess repeatedly. Allowing the call to continue, it never enters RpcBrokerConfiguration#init.
Has anyone else seen this before and are there any recommendations to fixing the issue or clues as to how we can debug it further? Thanks.
PS - this references Corda errorCode 1crywct.
FWIW, I would check for other processes using the same ports or just change the port via the node driver. For example the YourKit shipped with Intellij runs by default on port 10001 i.e. on the default node driver notary port - well, assuming i remember correctly.
I figured it out. My project is a CordaRPC client. It had a version of a third party lib that was conflicting with the version number that's used in Corda. This seems to make quasar go into a long loop attempting to resolve types! Fixing the conflict, fixed the issue. Perhaps there's something that Corda can do to give more clues when this happens.
Related
I get this error while running my unit test, while initializing the network parameters, this package com.example.contract does exist in my cordapp.
network = MockNetwork(MockNetworkParameters(cordappsForAllNodes = listOf(
TestCordapp.findCordapp("com.example.contract"),
TestCordapp.findCordapp("com.example.schema")
java.lang.IllegalArgumentException: There are no CorDapps containing the package com.example.contract on the classpath. Make sure the package name is correct and that the CorDapp is added as a gradle dependency.
I had the same issue with .findCordapp() In my case the problem was the classpath. I was running the tests in Intellij with the “JAR manifest” option selected for the “shorten command line” option in my Run configurations and that was causing the issue apparently, so instead I selected "none" option and it worked fine. I'm still investigating around this but for the moment I hope this throws some light to your problem so you can go on with your testing.
Please check the intellij Run/Debug Configurations if the tests are being run as gradle task rather then a junit one. Since the gradle tasks are the one which can scan the packages for cordapps.
While click run on my project in qt creator
" Failed to start program. Path or permissions wrong?"
11:02:18: Starting C:\V6\Filename2.0\release\Filename.exe...
11:02:18: Failed to start program. Path or permissaions wrong?
11:02:18: C:/V6/Filename2.0/release/Filename.exe exited with code -1
11:02:18: The process failed to start. Either the invoked program "C:/V6/Filename2.0/release/Filename2.exe" is missing, or you may have insufficient permissions to invoke the program.
Without more information (Qt and Qt Creator version, OS version - I assume it's windows) it's difficult to formulate a sensible hypothesis, however, off the top of my head some things you might try:
are you sure there's not another Filename.exe running? if there is QtCreator cannot create a new executable replacing current one that is in use
maybe windows holds some lock on that particular file / folder, it might be worth checking with tools like mst isusedby
try closing QtCreator / rebooting to clean any stale locks on that folder
in the projects section choose another folder for shadow building and see if the executable can be created there.
It could be due to executable file name , as pointed out in this answer : Qt: Cannot execute '': The requested operation requires elevation that shows another error message, this happens if executable file name contains or ends with "install", "update", "setup", "patch".
On the other hand, its possible to explicitly set (access level) manifist in the .pro with Admin privileges required:
QMAKE_LFLAGS += /MANIFESTUAC:\"level=\'requireAdministrator\' uiAccess=\'false\'\"
Or, to set access for current user:
QMAKE_LFLAGS += /MANIFESTUAC:\"level=\'asInvoker\' uiAccess=\'false\'\"
A bit late, but I have had this issue, caused by a target flag set as :
TARGET = runme.exe
in my .pro file.
Removing the extension,and changing it to just :
TARGET = runme
has solved this issue for me.
I am doing the Pintos project on the side to learn more about operating systems. I had tons of devops trouble at first with it not running well on an 18.04 Ubuntu droplet. I am now running it on the VirtualBox image that UCCS tells students to download for pintos.
I finished project 1 and started to map out my solution to project 2. Following the instructions to create a file I ran
pintos-mkdisk filesys.dsk --filesys-size=2
pintos -- -f -q
but am getting error
Kernel PANIC at ../../threads/vaddr.h:87 in vtop(): assertion
`is_kernel_vaddr (vaddr)' failed.
I then tried running make check (all the tests). They are all failing for the same reason.
Am I missing something? Is there something I need to implement to fix this? I reread the instructions and didnt see anything?
Would appreciate help!
Thanks
I had a similar problem. My code for Project 1 ran fine, but I could not format the filesystem for Project 2.
The failure for me came from the following call chain:
thread_init() -> ... -> thread_schedule_tail() -> process_activate() -> pagedir_activate() -> vtop()
The problem is that init_page_dir is still NULL when pagedir_activate() is called. init_page_dir should have been initialized in paging_init() but this is called after thread_init().
The root cause was that my scheduler was being called too early, i.e. before the call to thread_start(). The reason for my problem was that I had built in a call to thread_yield() upon completion of every call to lock_release() which makes sense from a priority donation standpoint. Unfortunately, locks are used prior to the scheduler being ready! To fix this, I installed a flag called threading_started that bails in the first line of my thread_block() and thread_yield() functions if thread_start() has not yet been called.
Good luck!
Getting this error soon after running riak start despite a config file that should be working correctly.
Turns out that this is a limit of Riak's error messaging: you will get the above message if you try to do a riak-admin test on your setup before the configuration has finished loading.
I encountered the same problem while starting new Riak clusters over and over again during automated testing. My solution was, in my test fixture setup, to execute code that keeps trying to put an object into a Riak bucket and then eventually succeeding.
Granted, my solution here is an Erlang snippet but it generally solves this problem in lieu of any Riak-supplied admin/wait functions. But since I've used a number of different Riak versions this technique here seems to work for all of them.
wait_for_riak() ->
{ok, C} = riak:local_client(),
io:format("Waiting for Raik..."),
wait_for_riak(C),
io:format("and had a successful put.~n").
wait_for_riak(C) ->
Strawman = riak_object:new(<<"test">>, <<"strawman">>, []),
case C:put(Strawman, 1) of
ok ->
ok;
_Error ->
receive after 1000 -> ok end,
wait_for_riak(C)
end.
adding sleep 4 like so:
brew install riak
riak start
sleep 4
riak-admin test
should help
I wrote this simple prototype client to send commands to a server I'm developing. It works perfectly running in GHCi, but the compiled version buffers everything typed in until I type in "quit" and the program exits. At that point all the input text gets sent.
What am I doing wrong? And why is it different when compiled?
Update: it does work as expected if compiled with ghc Main.hs. The problem happens when compiled with Leksah via Package -> Build. Anyone know how to get the command line Leksah is using?
System info: OSX 10.6, GHC 7.0.3, network 2.3.0.2
module Main (
main
) where
import System.IO
import Network
main = do
hServer <- connectTo "localhost" (PortNumber 7000)
hSetBuffering hServer NoBuffering
loop hServer
hClose hServer
where loop :: Handle -> IO ()
loop hServer = do
s <- getLine
hPutStrLn hServer s
case s of "quit" -> return ()
otherwise -> loop hServer
Leksah uses "cabal build", older versions "runhaskell Setup build".
Hmm, it seems Leksah wasn't actually building the app when I thought it was. I must have been running old code without the hSetBuffering call. A clean & rebuild has sorted it out. Apologies and thanks to everyone for your time and help.
edit: Found it - in case anyone else gets confused by this, when package->build is clicked, Leksah does not generate a compiled app if it's in debug/ghci mode.