public functions does not have a correct function name

[ferOnti]

using the command line wrapper generator, the functions for public variables are generated with invalid function name. (this is happening with variables with type array of structs)

Example:

struct Thing {
    string id;
    string name;
}

Thing[]    public things;

the generate function is like:

   Function function = new Function("org.web3j.abi.datatypes.generated.Uint256", 
            Arrays.<Type>asList(param0), 

instead:

    Function function = new Function("things", 
            Arrays.<Type>asList(param0), 

[conor10]

Please could you provide the ABI file?

[conor10]

Fixed in https://github.com/web3j/web3j/releases/tag/v1.1.1

[ferOnti]

thank you very much for solving this issue, I’m testing now, and it is ok. but I have another question, and before post it in github, I was thinking to share with you, the problem is, I want to send many transactions with the same account for the same block, because I have a stream of data, and that stream generates transactions quickly, and all of those transactions should be processed in the smart contract. But with current implementation of web3j, I can send only one transaction per account, because nonce is not incremented until the block is completed. I tried with NodeJS and web3 and I successfully sent many transactions with the same account but I increased manually the nonce before send every transaction. Do you think this issue, is something for we3j roadmap? I’m checking the code of we3j library, and seems possible to add this feature, but I will need some time to understand all the code behind the library.

…

On Jan 3, 2017, at 5:32 AM, Conor Svensson ***@***.***> wrote: Fixed in https://github.com/web3j/web3j/releases/tag/v1.1.1 <https://github.com/web3j/web3j/releases/tag/v1.1.1> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#34 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABmjK-OMAbzLwuv7qjHXPqew99jUlRtWks5rOhW2gaJpZM4LQxLV>.

[conor10]

No problem - this certainly sounds like useful functionality to have.

Feel free to raise an issue for this feature.

I think the main complexity is how best to support it without passing on the nonce management burden to the users of the library - ideally I'd like to hide this complexity, as I've always wanted to keep the API as straight forwards as possible.

It may make sense to create a separate nonce manager behind the scenes which tracks nonces locally for higher throughput applications. That way, only those users with high throughput needs would need to use it. The others could use the current, default implementation.

I'd be happy to accept a pull request providing this functionality :)

[ferOnti]

Hey, sorry to disturb, but I did a nonce manager by account off-the library, and it is working now, is sending 29 txs/block and that is impressive, but from time to time I got this error message, "rlp: non-canonical integer (leading zero bytes) for *big.Int, decoding into (types.Transaction)(types.txdata).S” I don’t know why this is happening, I tried to follow the code, but I’m lost, Maybe could you point me to understand what is happening and how to avoid this error, in case you want to check I have two “tcpdumps” of the transactions sent, the first one was processed successfully in the blockchain, but the second one raised the error message: {"jsonrpc":"2.0","method":"eth_sendRawTransaction","params":["0xf9016e82045885123456789a840409600094e911781292bbfbea96e0f14fd5f16294eeda3eb080b90104a3747fef000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a0000000000000000000000000000000000000000000000000000000000000003175726e3a6570633a69643a736774696e3a37333338333634342e36363831362e3030303030303030303335353034393200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004035343300313432383738330062697a53746570320062697a4c6f6332006e616d6500736b756e756d6265722d31323334350066616374757261003132333435001ba0897c2403637a238179574e7a5a2c3b2b2199c97e765bbf174831d52354c9e6bba02dfa9177233ddab21e90e71a748f1c42b376e96bdfbd246b5c6847f18f2c311b"],"id":1} {"jsonrpc":"2.0","method":"eth_sendRawTransaction","params":["0xf9016e82045985123456789a840409600094e911781292bbfbea96e0f14fd5f16294eeda3eb080b90104a3747fef000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000a0000000000000000000000000000000000000000000000000000000000000003175726e3a6570633a69643a736774696e3a32363633323332382e36353137342e3030303030303030303232343738323400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004035343300313432383738330062697a53746570320062697a4c6f6332006e616d6500736b756e756d6265722d31323334350066616374757261003132333435001ba08e396ddcf751b7bc06c7198a06b30fee90b6a84904ac33abd7907b9f8541958ca000594f5187b1d093d69222cab0afedd584963ce43b7eeb2f253e3bb61d8a826b"],"id":1} and this is the response I have: { "jsonrpc": "2.0", "id": 2, "error": { "code": -32000, "message": "rlp: non-canonical integer (leading zero bytes) for *big.Int, decoding into (types.Transaction)(types.txdata).S" } }

…

On Jan 3, 2017, at 8:04 PM, Conor Svensson ***@***.***> wrote: No problem - this certainly sounds like useful functionality to have. Feel free to raise an issue for this feature. I think the main complexity is how best to support it without passing on the nonce management burden to the users of the library - ideally I'd like to hide this complexity, as I've always wanted to keep the API as straight forwards as possible. It may make sense to create a separate nonce manager behind the scenes which tracks nonces locally for higher throughput applications. That way, only those users with high throughput needs would need to use it. The others could use the current, default implementation. I'd be happy to accept a pull request providing this functionality :) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#34 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABmjK9UkZ0h-1LeoV5PCIg39dGnpYmq0ks5rOuINgaJpZM4LQxLV>.

[conor10]

That's a decent transaction throughput to get.

Is there a quantity value in your pre-encoded request that is being specified with a leading zero, e.g. 0x0... - as these are not supported in the JSON-RPC API - see https://github.com/ethereum/wiki/wiki/JSON-RPC#hex-value-encoding.