EmptyMap, HashMap, SingletonMap , LinkedHashMap are not registered in Kryo by default and need to be registered manually in CorDapp.

Hi,
the following maven remote repos are unreachable
urls :

• r3.bintray.com/corda
• dl.bintray.com/kotlin/exposed

For the development purpose we have Driver class which must implement releasing web app port if you are closing application _or_killing application, most of the time i faced the issue after restarting application it throws error port already in use . Each time i have to go on cmd and do killall java

However when i use application from Intelij i see frequency is quite low, from command line this issue is most often.

I have a full review pending on my plate, but so far:

1. Tree does not cover all aspects of the transaction (notary, timestamp, etc are missing)
2. Duplicated last item causes same issue as in bitcoin: might not be exploitable as duplicate commands don't have any effect and duplicate attachments are invalid, but still should be fixed properly.

A few minor formatting issues but nothing an auto-reformat can't fix. I'll try and take a look at this stuff before Christmas.

This looks timing related and seems to be happening on my PR branch but does not reproduce individually. My high level assessment of this is that there's an attempt to notify an RPC client of a flow progress via the ProgressTracker but the node is in the process of shutdown and has nulled out the messaging producer as part of node messaging shutdown sequence. We should silently swallow I suspect.

Exception in thread "Node thread" rx.exceptions.OnErrorNotImplementedException: kotlin.KotlinNullPointerException
at rx.internal.util.InternalObservableUtils$ErrorNotImplementedAction.call(InternalObservableUtils.java:386)
at rx.internal.util.InternalObservableUtils$ErrorNotImplementedAction.call(InternalObservableUtils.java:383)
at rx.internal.util.ActionSubscriber.onError(ActionSubscriber.java:44)
at rx.observers.SafeSubscriber._onError(SafeSubscriber.java:153)
at rx.observers.SafeSubscriber.onError(SafeSubscriber.java:115)
at rx.exceptions.Exceptions.throwOrReport(Exceptions.java:216)
at rx.observers.SafeSubscriber.onNext(SafeSubscriber.java:139)
at rx.internal.operators.OperatorMaterialize$ParentSubscriber.onNext(OperatorMaterialize.java:112)
at rx.internal.operators.OnSubscribeMap$MapSubscriber.onNext(OnSubscribeMap.java:77)
at rx.subjects.PublishSubject$PublishSubjectProducer.onNext(PublishSubject.java:304)
at rx.subjects.PublishSubject$PublishSubjectState.onNext(PublishSubject.java:219)
at rx.subjects.PublishSubject.onNext(PublishSubject.java:72)
at net.corda.core.utilities.ProgressTracker.setCurrentStep(ProgressTracker.kt:133)
at net.corda.node.services.statemachine.FlowStateMachineImpl.run(FlowStateMachineImpl.kt:114)
at net.corda.node.services.statemachine.FlowStateMachineImpl.run(FlowStateMachineImpl.kt:33)
at co.paralleluniverse.fibers.Fiber.run1(Fiber.java:1067)
at co.paralleluniverse.fibers.Fiber.exec(Fiber.java:767)
at co.paralleluniverse.fibers.RunnableFiberTask.doExec(RunnableFiberTask.java:100)
at co.paralleluniverse.fibers.RunnableFiberTask.run(RunnableFiberTask.java:91)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at net.corda.node.utilities.AffinityExecutor$ServiceAffinityExecutor$1$thread$1.run(AffinityExecutor.kt:67)
Caused by: java.util.concurrent.ExecutionException: kotlin.KotlinNullPointerException
at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357)
at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1895)
at net.corda.node.utilities.AffinityExecutor$DefaultImpls.fetchFrom(AffinityExecutor.kt:41)
at net.corda.node.utilities.AffinityExecutor$ServiceAffinityExecutor.fetchFrom(AffinityExecutor.kt:53)
at net.corda.node.services.messaging.NodeMessagingClient$createRPCDispatcher$1.send(NodeMessagingClient.kt:447)
at net.corda.node.services.messaging.RPCDispatcher$ObservableSerializer$write$subscription$1.call(RPCDispatcher.kt:69)
at net.corda.node.services.messaging.RPCDispatcher$ObservableSerializer$write$subscription$1.call(RPCDispatcher.kt:52)
at rx.internal.util.ActionSubscriber.onNext(ActionSubscriber.java:39)
at rx.observers.SafeSubscriber.onNext(SafeSubscriber.java:134)
... 15 more
Caused by: kotlin.KotlinNullPointerException
at net.corda.node.services.messaging.NodeMessagingClient$createRPCDispatcher$1$send$1.invoke(NodeMessagingClient.kt:454)
at net.corda.node.services.messaging.NodeMessagingClient$createRPCDispatcher$1$send$1.invoke(NodeMessagingClient.kt:445)
at net.corda.node.utilities.AffinityExecutor$fetchFrom$1.get(AffinityExecutor.kt:41)
at java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1590)
... 3 more

E:\work_ch\blockchain\corda-master>gradlew.bat samples:trader-demo:deployNodes
Download https://repo1.maven.org/maven2/com/google/guava/guava/19.0/guava-19.0.j
ar

FAILURE: Build failed with an exception.

• What went wrong:
  Could not resolve all dependencies for configuration ':runtime'.

Could not download guava.jar (com.google.guava:guava:19.0)
Could not get resource 'https://repo1.maven.org/maven2/com/google/guava/gua
va/19.0/guava-19.0.jar'.
> Premature end of Content-Length delimited message body (expected: 230851
7; received: 1387997

• Try:
  Run with --stacktrace option to get the stack trace. Run with --info or --debug
  option to get more log output.

BUILD FAILED

Total time: 1 hrs 28 mins 5.013 secs

Scenario:
I run the attachment demo.
All nodes run in background.
I cd to a node (e.g. nodea) directory and run java -jar corda.jar.
Corda kindly checks if there is other application running from the same directory and exits.

Issue
it starts to write to logs before making a check, what means that original logs are overwrite. I think they are properly archived into archive subdirectory (BTW I expected to find them in logs directory), but the ‘main’ logs file is gone.

As a user, I want to be able to find attachments I have uploaded previously for use in new transactions.

As an administrator, I want to be able to identify what attachments a node has.

To fulfil this, attachment storage should track metadata about attachments, including:

• Original filename
• Upload date
• Uploader

It may also be useful to track MIME type, and to be able to tag attachments so that they can be searched for in some meaningful way. Tags could potentially include the CorDapp that the attachment was uploaded via, as this is likely to be a common way of filtering.

Very_simple_Shell_Script_to_load_Corda_Transactions.txt
Error_Output_.txt

(Very low low priority issue)

When running "irs-demo.bat --role UploadRates" I get the output:

C:\Users\cleme\Documents_Dev\corda\corda\samples\irs-demo\build\install\irs-demo\bin>irs-demo.bat --role UploadRates
The input line is too long.
The syntax of the command is incorrect.

I was able to switch back to gitbash and run ./irs-demo --role UploadRates successfully

The test "NodeMonitorModelTest.cash issue and move" test is failing often on CI, but it is not every time.

An example of a failure on a branch that passed on a later run is here. This branch is also merged into master which has passed since.

Applications are supposed to communicate with Corda via RPC. However, the RPC client code net.corda.node.services.messaging.CordaRPCClient is currently tightly integrated with the Node code itself. This RPC client needs to be broken out into a separate module so that other projects can use it.

This refactoring will almost certainly involve the creation of additional sub-modules, e.g. a basic utilities module and an RPC API module.

If we start up a local network "network map", "node a", then it works reliably. The other way around sometimes works and sometimes doesn't - node a hangs waiting for the network map registration to complete. It's meant to work, so the runnodes script doesn't impose any ordering on startup and it ends up being a race as all nodes start in parallel.

I suspect something in the network map service is taking messages off the queue and then dropping them on the floor during startup. As the node will try connect/delivery in the background, the moment the network map node starts it will be sent queued messages.

Currently tracking any details about a transaction are left to individual CorDapps, which both makes it very difficult to understand what has happened without searching CorDapps individually, and requires effectively reinventing the wheel to track what is likely quite common data in each CorDapp.

It would be beneficial if the vault could track:

• CorDapp(s) involved in creating a transaction, ideally down to the state/command level
• User(s) involved in creating a transaction, as identified by the CorDapp

It may be desirable to extend this to a permission system that restricts transactions so they are not generally visible to CorDapps/users who are not involved, however this requires significant further design (some CorDapps/users will have special permissions, for example).

The Java compiler gives the following error:

/Users/shamsasari/git/corda/finance/src/main/java/net/corda/contracts/JavaCommercialPaper.java:43: error: A is not abstract and does not override abstract method call() in FlowLogic
    public static class A extends AbstractStateReplacementFlow.Acceptor<String> {
                  ^

Adding

@Override
public void call() throws StateReplacementException {
    super.call();
}

gives:

/Users/shamsasari/git/corda/finance/src/main/java/net/corda/contracts/JavaCommercialPaper.java:43: error: A is not abstract and does not override abstract method call() in FlowLogic
    public static class A extends AbstractStateReplacementFlow.Acceptor<String> {
                  ^
/Users/shamsasari/git/corda/finance/src/main/java/net/corda/contracts/JavaCommercialPaper.java:54: error: call() in A cannot override call() in FlowLogic
        public void call() throws StateReplacementException {
                    ^
  return type void is not compatible with Unit
  where T is a type-variable:
    T extends Object declared in class FlowLogic

The issue seems to be the Kotlin compiler compiles AbstractStateReplacementFlow.Acceptor.call() to return void which the Java compiler doesn't like because FlowLogic.call() returns Object.

Until this is fixed in Kotlin I suggest we have Acceptor be of some type other than Unit - the type doesn't matter because it's service flow. We will also need to make sure there aren't other Unit flows which are designed to be extended.

Hi there,

After read the tech white paper, i have one question about how notary works. If two parties has done several transactions via different notaries, how would a third party join them? Can someone explain the procedure please?

Trying to run the nodes for both the attachment, simm and dist notary demos using the run configs on master causes the following msg to appear:

Listening for transport dt_socket at address: 5005
Listening for transport dt_socket at address: 5006
Listening for transport dt_socket at address: 5007
Listening for transport dt_socket at address: 5008
Process finished with exit code 0

The following steps then fail.

Background: Transaction demarcation (begin, commit, rollback) is currently handled by Exposed within Corda. We have recently introduced a new persistence engine called Requery (initially used within the Vault and for Attachments persistence) - which has been configured to delegate transaction handling to the outer Exposed transaction (eg. all calls to Requery SQL DSL operations are expected to be managed within an outer Exposed transaction - if one does not already exist, then one is automatically created using the Exposed session connection).

In the attached screenshot, please see the inability to add an issuer. Thanks !

Thanks !

Example stack trace:

11:27:33.243 [QUIET] [system.out] E 11:27:33 1 Main.main - Exception during node startup
11:27:33.243 [QUIET] [system.out]  java.net.BindException: Address already in use
11:27:33.243 [QUIET] [system.out]   at sun.nio.ch.Net.bind0(Native Method) ~[?:1.8.0_92]
11:27:33.243 [QUIET] [system.out]   at sun.nio.ch.Net.bind(Net.java:433) ~[?:1.8.0_92]
11:27:33.243 [QUIET] [system.out]   at sun.nio.ch.Net.bind(Net.java:425) ~[?:1.8.0_92]
11:27:33.243 [QUIET] [system.out]   at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) ~[?:1.8.0_92]
11:27:33.243 [QUIET] [system.out]   at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) ~[?:1.8.0_92]
11:27:33.243 [QUIET] [system.out]   at io.netty.channel.socket.nio.NioServerSocketChannel.doBind(NioServerSocketChannel.java:125) ~[netty-all-4.0.39.Final.jar:4.0.39.Final]
11:27:33.243 [QUIET] [system.out]   at io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:501) ~[netty-all-4.0.39.Final.jar:4.0.39.Final]
11:27:33.243 [QUIET] [system.out]   at io.netty.channel.DefaultChannelPipeline$HeadContext.bind(DefaultChannelPipeline.java:1218) ~[netty-all-4.0.39.Final.jar:4.0.39.Final]
11:27:33.243 [QUIET] [system.out]   at io.netty.channel.AbstractChannelHandlerContext.invokeBind(AbstractChannelHandlerContext.java:505) ~[netty-all-4.0.39.Final.jar:4.0.39.Final]
11:27:33.244 [QUIET] [system.out]   at io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:490) ~[netty-all-4.0.39.Final.jar:4.0.39.Final]
11:27:33.244 [QUIET] [system.out]   at io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelPipeline.java:965) ~[netty-all-4.0.39.Final.jar:4.0.39.Final]
11:27:33.244 [QUIET] [system.out]   at io.netty.channel.AbstractChannel.bind(AbstractChannel.java:210) ~[netty-all-4.0.39.Final.jar:4.0.39.Final]
11:27:33.244 [QUIET] [system.out]   at io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap.java:353) ~[netty-all-4.0.39.Final.jar:4.0.39.Final]
11:27:33.244 [QUIET] [system.out]   at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:408) ~[netty-all-4.0.39.Final.jar:4.0.39.Final]
11:27:33.244 [QUIET] [system.out]   at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:402) ~[netty-all-4.0.39.Final.jar:4.0.39.Final]
11:27:33.244 [QUIET] [system.out]   at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:140) ~[netty-all-4.0.39.Final.jar:4.0.39.Final]
11:27:33.244 [QUIET] [system.out]   at java.lang.Thread.run(Thread.java:745) ~[?:1.8.0_92]

Fresh repo clone of both corda and cordapp-template (both master), following the instructions in the developer docs.

1. gradlew deployNodes is successful
2. runnodes causes nodes to start successfully, including webserver.
3. node processes are terminated.
4. restart of nodes (either together with runnodes, or individually by 'build/nodes/nodea; java -jar corda.jar && exit') causes nodes to restart successfully, but the webserver is not started. There are no warning or error messages displayed.

The log file produced during startup (which contains the node configuration) is attached.
node-Jamess-MacBook.local.txt

Note that gradlew clean, followed by gradlew deployNodes and then runnodes will cause the webserver to start normally.

I'm getting a compilation error.

$ git clone https://github.com/corda/corda && cd corda
$ ./gradlew build --info

...
Executing task ':node:compileKotlin' (up-to-date check took 0.027 secs) due to:
  No history is available.
All input files are considered out-of-date for incremental task ':node:compileKotlin'.
e: /home/lin/git/corda/node/src/main/kotlin/net/corda/node/utilities/JDBCHashMap.kt: (208, 27): Inherited platform declarations clash: The following declarations have the same JVM signature (remove(Ljava/lang/Object;Ljava/lang/Object;)Z):
    fun remove(key: Any, value: Any): Boolean
    fun remove(key: Int, value: MutableList<AbstractJDBCHashMap.NotReallyMutableEntry<K, V>>): Boolean
e: /home/lin/git/corda/node/src/main/kotlin/net/corda/node/utilities/JDBCHashMap.kt: (208, 27): Inherited platform declarations clash: The following declarations have the same JVM signature (getOrDefault(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;):
    fun getOrDefault(key: Any!, defaultValue: MutableList<AbstractJDBCHashMap.NotReallyMutableEntry<K, V>>!): MutableList<AbstractJDBCHashMap.NotReallyMutableEntry<K, V>>!
    fun getOrDefault(key: Int, defaultValue: MutableList<AbstractJDBCHashMap.NotReallyMutableEntry<K, V>>): MutableList<AbstractJDBCHashMap.NotReallyMutableEntry<K, V>>
[KOTLIN] deleting /home/lin/git/corda/node/build/kotlin-classes/main on error
:node:compileKotlin FAILED
:node:compileKotlin (Thread[Daemon worker Thread 4,5,main]) completed. Took 8.533 secs.

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':node:compileKotlin'.
> Compilation error. See log for more details

* Try:
Run with --stacktrace option to get the stack trace. Run with --debug option to get more log output.

BUILD FAILED

Total time: 9.99 secs
Stopped 0 compiler daemon(s).
Received result Failure[value=org.gradle.initialization.ReportedException: org.gradle.internal.exceptions.LocationAwareException: Execution failed for task ':node:compileKotlin'.] from daemon DaemonInfo{pid=1649, address=[e113a0d0-65be-4fa2-92dd-a42b2a44d6e7 port:42906, addresses:[/0:0:0:0:0:0:0:1, /127.0.0.1]], state=Idle, lastBusy=1480641783766, context=DefaultDaemonContext[uid=af9bccf2-fe94-4e93-ac92-807b52d36f77,javaHome=/usr/lib/jvm/java-8-oracle,daemonRegistryDir=/home/lin/.gradle/daemon,pid=1649,idleTimeout=10800000,daemonOpts=-XX:MaxPermSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xmx1024m,-Dfile.encoding=UTF-8,-Duser.country=US,-Duser.language=en,-Duser.variant]} (build should be done).

i am trying to run the trader-demo nodes on three different machines.Notary node is succesfully started but the other nodes are not getting started.I had kept network mapping address for the node a and node b as the ip address of the machine where the notary node was running and port on which the notary node is running.But only the notary node is started but the others nodes are not started.why?

node.conf of notary

artemisAddress="ipaddress of 1st machine:10002"
basedir=notary
extraAdvertisedServiceIds="corda.notary.validating"
myLegalName=Notary
nearestCity=London
rpcUsers=[]
webAddress="ipaddress of 1st machine:10003"

node.conf of nodea

artemisAddress="ipaddress of 2nd machine:10004"
basedir=nodea
extraAdvertisedServiceIds=""
myLegalName="Bank A"
nearestCity=London
networkMapAddress="ipaddress of 1st machine:10002"
rpcUsers=[]
webAddress="ipaddress of 2nd machine:10005"

node.conf of nodeb

artemisAddress="ipaddress of 3rd machine:10006"
basedir=nodeb
extraAdvertisedServiceIds=""
myLegalName="Bank B"
nearestCity="New York"
networkMapAddress="ipaddress of 1st machine:10002"
rpcUsers=[]
webAddress=ipaddress of 3rd machine:10007"

On a Windows 10 VM, runnodes in the cordapp-template throws up 10s/100s of terminal windows, which eventually close, leaving only the node terminals.

Hi. After setting up Corda on Ubuntu 16 there is an error while trying to compile using command line and gradle.

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':client:compileKotlin'.
> Compilation error. See log for more details

Both on the local ubuntu laptop and AWS EC2 Instance.
Seems to be kotlin installation problem, any ideas?

Node fails to start when using Oracle JDK 8u20.

Paths.get("").normalize() throws ArrayIndexOutOfBoundsException. This is a documented bug:
http://bugs.java.com/view_bug.do?bug_id=8042751

Stack trace:

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
  at sun.nio.fs.UnixPath.normalize(UnixPath.java:508)
  at net.corda.node.services.config.ConfigHelper.loadConfig(ConfigUtilities.kt:34)
  at net.corda.node.services.config.ConfigHelper.loadConfig$default(ConfigUtilities.kt:30)
  at net.corda.node.MainKt.main(Main.kt:74)

Solution is to upgrade JDK above version 1.8.0_20. Suggest we catch this exception and print the solution to screen -> Upgrade JDK above version 1.8.0_20 or something.

When specifying a dependent CorDapp in your build.gradle's Cordform task it does not pull the dependent CorDapp into your plugins directory. For example;

Say we have two CorDapp where CorDapp D depends on C in it's dependencies block;

cordapp project(':cordappC')

Then the below node definition should include this CorDapp C's JAR in the plugin directory of the generated node;

node {
    name "Controller"
    artemisPort 10002
    cordapps = ['net.corda:cordappD:1.0']
 }

Currently a workaround is to just specify CorDapp C in the cordapps array.

The test named in the title fails spuriously on CI.

A build log of a failing test can be found here: http://teamcity.corda.r3cev.com:8111/viewLog.html?buildId=1375&buildTypeId=Corda_PullRequests&tab=buildLog

I'm calling CordaOPS.startFlow from a web api registered in a Corda plugin registry:

val content = ByteArray(102400)
val ret = services.startFlow(::MyFlow, content).returnValue.get()

startFlow hangs for byte arrays greater than ~102300 bytes with the following warning:

W 15:44:13 56 rpc.run - Received malformed client RPC message: missing _AMQ_VALIDATED_USER property

Following the steps from https://docs.corda.net/running-the-demos.html#trader-demo, runnodes.bat seems to open up a window for each node but then they immediately close.

If a flow fails partway through, all the progress tracker steps are still printed to the console, giving the impression that the flow has succeeded.

Corda insists to to bind (I believe Artemis) to the interface with public hostname/IP address. This doesn't necessary equal IP address visible in the internet. Actually, in cloud (Azure for sure) it's not equal.

[ERROR] 2017-02-23T10:33:52,544 [main] Main.main - Exception during node startup
org.apache.activemq.artemis.api.core.ActiveMQNotConnectedException: AMQ119007: Cannot connect to server(s). Tried with all available servers.
        at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:785) ~[artemis-core-client-1.5.1.jar:1.5.1]
        at net.corda.node.services.messaging.NodeMessagingClient.start(NodeMessagingClient.kt:127) ~[node-0.9-SNAPSHOT.jar:?]
        at net.corda.node.internal.Node.startMessagingService(Node.kt:151) ~[node-0.9-SNAPSHOT.jar:?]
        at net.corda.node.internal.AbstractNode$start$3.invoke(AbstractNode.kt:263) ~[node-0.9-SNAPSHOT.jar:?]
        at net.corda.node.internal.AbstractNode$start$3.invoke(AbstractNode.kt:75) ~[node-0.9-SNAPSHOT.jar:?]
        at net.corda.node.internal.AbstractNode$initialiseDatabasePersistence$2.invoke(AbstractNode.kt:321) ~[node-0.9-SNAPSHOT.jar:?]
        at net.corda.node.internal.AbstractNode$initialiseDatabasePersistence$2.invoke(AbstractNode.kt:75) ~[node-0.9-SNAPSHOT.jar:?]
        at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManagerKt.inTopLevelTransaction(ThreadLocalTransactionManager.kt:69) ~[exposed-0.5.0.jar:?]
        at org.jetbrains.exposed.sql.transactions.ThreadLocalTransactionManagerKt.transaction(ThreadLocalTransactionManager.kt:57) ~[exposed-0.5.0.jar:?]
        at net.corda.node.utilities.DatabaseSupportKt.databaseTransaction(DatabaseSupport.kt:39) ~[node-0.9-SNAPSHOT.jar:?]
        at net.corda.node.internal.AbstractNode.initialiseDatabasePersistence(AbstractNode.kt:320) ~[node-0.9-SNAPSHOT.jar:?]
        at net.corda.node.internal.Node.initialiseDatabasePersistence(Node.kt:201) ~[node-0.9-SNAPSHOT.jar:?]
        at net.corda.node.internal.AbstractNode.start(AbstractNode.kt:202) ~[node-0.9-SNAPSHOT.jar:?]
        at net.corda.node.internal.Node.start(Node.kt:206) ~[node-0.9-SNAPSHOT.jar:?]
        at net.corda.node.Corda.main(Corda.kt:109) [node-0.9-SNAPSHOT.jar:?]```

Upgrading to the latest RxJava fails due to a subscriber to the dbtx close observables not supporting backpressure properly (very likely the wrapper class). See PR #99 for a discussion. A tip from the RxJava devs:

Enable assembly tracking with RxJavaHooks.enableAssemblyTracking() around a unit test that fails and you'll get more detailed exceptions about what failed (most likely). But first make sure you don't call onNext concurrently on the PublishSubject.

Corda documentation (e.g. https://docs.corda.net/setting-up-a-corda-network.html ) indicates that build JAR(s) will appear in <PROJECT_ROOT>/build/libs, but after M6 it's <PROJECT_ROOT>node/capsule/build/libs.

Unfortunately, the field also auto-adds one when it is selected, hence making the submission process fail.

I an getting the below exception

A problem occurred evaluating root project 'corda'.

Project with path ':node' could not be found in root project 'corda'.

• Try:
  Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 13.892 secs
Project with path ':node' could not be found in root project 'corda'.

Stacktrace from build server at: http://teamcity.corda.r3cev.com:8111/viewLog.html?buildId=893&buildTypeId=Corda_CordaBuild&tab=buildLog

The specific test is:

[net.corda.node.services.ScheduledFlowTests] create and run scheduled flow then wait for result

It's a spurious one so the repro steps are to run the test until it fails.

Hi,

My build was working perfectly fine until i did a pull from master recently. Now the build fails with unresolved reference errors in NodeVaultSchemaTest.kt

I have invalidated caches and restarted but this doesn't solve the issue.

On my fork you can see a fixed branch which is a working version before the latest pull into master which creates this error, does the build pass on your build management server?

Thanks

Bank of Corda demo code

I think the pattern is that if you attempt a cash payment transaction which takes the value balance below 0 (i.e. insufficient funds) this takes down the explorer. (i.e. thrown corda transaction error not caught properly)
I think - may need a bit more debugging.

Running the trader demo will result in the following error message for node B:

E 14:02:19 31 ArtemisMessagingServer.maybeDeployBridgeForNode - Don't know how to deal with NetworkMapAddress(hostAndPort=localhost:10002)

The issue seems to be with the controller node running the notary on top of being the network map service.

After running the simulation (runSimulationNodes) for a few minutes we get an OutOfMemoryError and nodes crash.
This is most likely caused by event generators just firing off new startFlow requests and never waiting for them to finish, which then queue up, eventually using up all memory.
We could just give it more memory, but I think it's better to fix this behaviour instead.

It might be worth having a basic test to check for regressions.

Runnodes doesn't allocate debug ports on any platform. This should be configurable.

Laptop suspend/wake cycles don't trigger rebuilds of the RPC connections. The cause is probably that client reconnection has to be explicitly configured and it's a TODO in CordaRPCClient:

// TODO: Configure session reconnection, confirmation window sizes and other Artemis features.

http://activemq.apache.org/artemis/docs/1.5.1/connection-ttl.html
http://activemq.apache.org/artemis/docs/1.5.1/client-reconnection.html

We should configure RPC to use these features, as having MQ-based RPC was done exactly to allow Artemis to take care of stuff like this for us. We can also consider a demo mode, in which session teardown on the server is configured for a very long time (like days) so people can suspend their laptops and resume without presentations being interrupted.

See the CI for an example.

Step 6 of the instructions here doesn't cause any rate fixing to occur. This is true even if you use the same future date (2018-01-01) used by IntelliJ's equivalent run config.