Messages posted by: nordhenr@gmail.com

Toli,

We have experience the same several times under Windows XP. This usually occurs when the ORS has been running for some time (always more than one day). I have had a quick look at the ORS log in these instances, but there is not much to be said apart from the fact that the FIX connection fails. The setup we use is running one ORS and usually connect with two strategy agents to it.

It is always helped by just restarting the ORS, even though it sometimes can take some time to figure out what the problem is..

Kind regards,

Henrik

Edit: My bad. This is a "feature" in Orc's FIX Gateway where only FIX tags 38, 40, 44, 59, 99, 126 432 could be changed.

Hi,

I think this topic might have been visited earlier, but this appears to be a new angle of the problem. Please let me know if I have misunderstood something. I am running Metc under Windows Vista/XP using revision 10792.

The scenario is as follows. I have an iceberg order (fix tag 111) which I want to replace with an ordinary order showing the whole size, i.e. I don't want the tag 111 anymore. I cannot seem to get this right however.

1. It does't help to not adding this tag to the new OrderSingle supplied to replaceOrder, since tags are copied from the original order.

2. Setting custom tags on the OrderReplace does not work.

3. Finally changing tags on the order already in the market before performing the replace does not work.

By having a quick look at the code, it appears this problem would be easily solved if the replaceOrder took the orignial order as an argument rather then the original order id.

Cheers,

Henrik

Yoram,

Thanks for your reply. I have gotten this error consistently for some months whenever I tried to check out the code. I will try to provide more information and file a bug report.

Kind regards,

Henrik

Thanks,

I will retry it now.

Regards,

Henrik

Hello,

Please see below error. It appears that the correct version of objenesis cannot be found.

Any suggestions how to fix it?

[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to resolve artifact.

Couldn't find a version in [1.2] to match range [1.0,1.0]
org.objenesis:objenesis:jar:null

from the specified remote repositories:
findbugs.googlecode.com (http://findbugs.googlecode.com/svn/repos/release-repository),
java.net (http://download.java.net/maven/2),
internal (http://repo.marketcetera.org/maven),
central (http://repo1.maven.org/maven2)

Kind regards,

Henrik

Hello,

I wanted to try out the latest Strategy framework and downloaded revision 10787 from the SVN server. However, when building the platform the JavaLanguageTest fails. This has not happened to me with earlier versions. Is this an error that I could "safely" ignore?

-------------------------------------------------------------------------------
Test set: org.marketcetera.strategy.JavaLanguageTest
-------------------------------------------------------------------------------
Tests run: 55, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 638.991 sec <<< FAILURE!
callbacksAfterStop(org.marketcetera.strategy.JavaLanguageTest) Time elapsed: 4.621 sec <<< FAILURE!
java.lang.AssertionError: The strategy should have been stopped before the callback - increase the callback delay
at org.junit.Assert.fail(Assert.java:91)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.marketcetera.strategy.LanguageTestBase.callbacksAfterStop(LanguageTestBase.java:1001)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:2

at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:73)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:46)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:2

at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165)
at org.apache.maven.surefire.Surefire.run(Surefire.java:107)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1005)

Kind regards,

Henrik

I have a problem which has been bothering me for some time now with the way Marketcetera handles order book updates following trades. I will explain below a few scenarios which cause the problem.

In the case where the order book changes state due to an order being added or removed, this will create one single QuoteEvent with the values ADD, CHANGE or DELETE. This can easily be processed by the OrderBook class in onBid/onAsk and we have an up to date snapshot. No problem here...

However, in the case where the state of the order book changes due to a trade, several quotes in the order book may change at the same time. Consider the following order book

BSize Bid Ask Asize
100 100 101 100
100 99 102 100

Followed by a limit sell order with size 200 at price 100, the new order book would be

BSize Bid Ask Asize
100 99 100 100
### ## 101 100

To fully update the order book to represent the latest order book we would have to process several QuoteEvent (e.g. one BidEvent.DELETE and one AskEvent.ADD). I can think of other more complex situations as well. The problem is that there is no way for the strategy to know that more events will be coming even though it is likely to be known in the market adapter. (Of course there times when you can realise the book is obviously wrong, but not the point here.) Hence, many times lots of analysis is done on an not up to date book.
I cannot see any easy solution to this problem. Ideally it would be nice to send a whole list of quotes to an onQuote method or similar.

Please let me know your thoughts!

Regards,

Henrik

Rich,

I never solved this problem myself, since I moved on to our brokers test market where this was a none issue.

Hope you can figure out something.

Regards,

Henrik

Anshul,

I read your filed request and believe that it should solve any problem. At the moment there is no way of getting the order for a specific orderID unless you created it by yourself, but by either returning the full order rather than the orderID for replace/cancel or create them in a separate step the control should be handed back to the strategy developer.

Personally I would find it convenient if I could generate a cancel/replace order by supplying the original order, e.g.

OrderSingle order = Factory.getInstance().createReplace(origOrder);

and then update only the changed parameters on order.

Regards,

Henrik

You don't need to compile them and no additional libs are required. Just run the java scripts in the same way as the ruby ones.

You can have a look here:

http://code.marketcetera.org/root/trunk/source/strategyagent/src/main/sample_data/samples/java/scripts/

and

http://code.marketcetera.org/root/trunk/source/strategyagent/src/main/sample_data/samples/java/inputs/

Regards,

Henrik

It's difficult to help you when you provide so little information.

Anyhow, the logs are store in java.io.tmpdir which you can find by running the following short program

In my case, I find them in C:\Users\Henrik\AppData\Local\Temp

I think you can configure it by changing photon-log4j.properties. Search your source folder to find it.

Regards,

Henrik

This is where I find mine: C:\Program Files\Marketcetera\METC-1.5\photon\logs

Hi,

I managed to work around this issue. Whenever replacing orders I need to submit the original orderId and the OrderSingle that I want to replace. The issue appears if we do two or more subsequent replace, since we will never be able to access the order created by the first replace. See below for explanation:

Step 1
Buy - orderId: xxxx1
Order is created using factory method, so we have a reference

Step 2
Replace #1 - orderId: xxxx2, origOrderId: xxxx1
This only results in an orderId, but there is no way of accessing the actual order. Hence, we have no order to pass to cancelReplace in step 3. The solution is to "predict" which orderId the cancelReplace will generate. Note that these number are generated from and AtomicLong, so it shouldn't be impossible however not ideal. Take this predicted orderId and update the original order according to order.setOrderId(predictedOrderId) before passing to cancelReplace.

Step 3
Replace #2 - orderId: xxxx3, origOrderId: xxxx2
By passing the updated order, this third step should now work.

Hopefully I have been at least remotely clear. I am sure there exists much simpler solutions, but this could be one way.

Regards,

Henrik

Hi again,

I have now updated to the latest revision as of Friday 17th , but I am not 100% sure I get the replace to work the way I believe it should do. Hence, I will shoot a couple of quick questions in order to debug my strategy. Hopefully we should be able to iron out any issues quickly by doing this.

My first questions is related to how I should create the OrderSingle sent to the cancelReplace. I see there are two different ways of doing it, and maybe both are supposed to work, but I prefer if you confirm.

1. The original OrderSingle is saved away, and the simply passed to cancelReplace along with it's original orderID and updated size and price.

2. Create a completely new order (e.g. OrderSingle order = Factory.getInstance().createOrderSingle() and set all the values from scratch.

The reason the first method is simpler for me is that I have several custom fields I need to add because of our broker. Once this is clear I will post a sample strategy showing my concern.

Thanks,

Henrik

Footer Links