Messages posted by: anshul

Strategy API provides methods to log information from within a strategy, which is the recommended mechanism to log information from within a Strategy.

Per documentation, ORS sends an ACK execution report immediately after sending the order to the broker. It does not store the outgoing order but it does store the ACK execution report.

The immediate ACK reports are sent with the status PENDING_xxx (where 'xxx' is the desired operation such as 'NEW', 'CANCEL', or 'REPLACE') and they have their Originator attribute set to Server.

If you do not want to see SINK messages in Strategy Agent stdout, you can comment out the following line from the conf/log4j.properties file. If you do this, the SINK output will only appear in the strategy agent log file. You'll notice that the logging category for sink is "SINK" not "org.marketcetera.SINK".

Strategy logging is intertwined with the operation of remote receiver module as the strategy module doesn't emit log events if the log level of the events is below the configured log level of the remote receiver module. This is done to avoid unnecessary performance overhead when strategies are remotely monitored. When you have remote receiver module installed in the strategy agent, you need to change the remote receiver's log level to change strategy's log level. By default, the remote receiver module is available in the strategy agent install and so its log level influences strategy logging.

The remote receiver's log level is specified in modules/conf/remote_receiver.properties file as the value of the property .LogLevel. To reset it to INFO, you can change that line as follows.

.LogLevel=INFO

Note that if you do not have the remote receiver module installed in the strategy agent (ie. you remove the remote receiver's jar from modules/jars subdirectory), strategy's logging is not influenced by the configuration of the remote receiver module. It's instead controlled by the logging category user.messages.

The 1.5.0 Strategy Module API doesn't allow you to emit arbitrary objects. This limitation has been addressed in the trunk. In the next release, you'll be able to emit arbitrary objects from a strategy.
And you'll be able to send those arbitrary objects from one strategy to another using the means outlined in your previous post.

CEP queries use the java bean syntax to name attributes on various java object types.

If you look through the javadoc for TradeEvent, you'll find the getSymbolAsString() method on the SymbolExchangeEvent class that TradeEvent inherits from. You'll also find the getPrice() and getSize() methods in it.

You are right in pointing out that the 1.5.0 Strategy Module API doesn't provide means to emit Map objects. This limitation has been addressed in the trunk. In the next release, not only will you be able to emit arbitrary object types from a Strategy, you will also be able to create data flows using the strategy module API.

In 1.5.0 the Strategy API only allows you to emit Events, Orders, Suggestions, Notifications & Log Events. The chart module is capable of handling SymbolExchangeEvents (to display the price on the bid/ask/trade events) and MarketstatEvents (to display the OHLC chart) as well. So if the data that you're wanting to plot can be displayed as either of these two charts, you can emit either of these two events with appropriate price or ohlc values directly into the chart module.

A workaround to emit map objects from the strategy is to emit objects of one of the types that Strategy API supports, say MarketstatEvent, to a CEP module and use a CEP query to emit certain attributes of that object in a map. For example, if you wanted to emit the values in open,high,low,close attributes of Marketstat event in a map with the keys axis1, axis2, axis3, axis4 you can create the following data flow from the strategy to the cep module to the chart module.

The strategy will emit MarketstatEvent objects with axis1, axis2, axis3, axis4 values in the open, high, low, close attributes of the event object. The CEP query will extract those attributes into a Map object which the chart module will be able to plot.

I haven't tested this so if you face problems in getting this to work, do post back.

Unable to execute command 'createDataFlow' at line number '16' with parameters metc:strategy:system:strategyOne;ALL^metc
:strategy:system:simulator because of error: 'Module 'metc:strategy:system:simulator' is unable to process request param
eter value 'null'.'. Continuing...

My bad... the framework is automatically appending the sink module to the dataflow and hence is requesting the 'simulator' strategy module to emit data. We get an error because we haven't specified any request parameters for that module in the data flow request.
To fix the problem, I'd try the following createDataFlow command:

If you already specified sink as the target for all emissions when creating the 'simulator' strategy module, you'd see duplicate log events emitted by the 'simulator' strategy in the sink.

You can also choose any of the other available OutputType values instead of LOG if you want.

See JRuby documentation for details on how to call java classes from ruby scripts.

If you author your own java classes and want to access those classes from strategy scripts when running them within strategyagent, you can copy the jar containing those classes into the modules/jars sub-directory of strategy agent. Classes from the jars in modules/jars sub-directory of strategy agent are accessible to strategy scripts.

It is possible for you to exchange data between strategies using the createDataFlow Strategy Agent command. Here's an exemplar strategy agent commands file that creates two strategies and sets up a data flow between them:

Another possibility is to designate the receiver strategy as the target for all emissions of orderSender when creating it. Like so:

Note that I haven't tested the commands above. If you run into issues with them, do post back.

Currently it is not possible for a strategy module to dynamically switch between sending orders/data to a simulator or another destination. This order/data destination is determined when the strategy is created. If this feature is important to you, I'll encourage you to file a feature request for it with details on the use-case.

Also note that we recently checked in changes to the strategy API which lets you create custom data flows using the strategy API. These changes will be available in the next release of the platform.

That's right. As far as I can tell, 1.5.0 ORS does not logout from the broker(s) when terminated.

I was looking at the code in the trunk when answering your question.
You can look at the diff between the latest code and 1.5.0 here in case it helps you figure out the changes needed to get ORS to logout from the broker(s) when it's terminated.

As far as I can tell, ORS should be logging out and disconnecting from brokers when it is terminated. Here is why:

OrderRoutingSystem.main() adds a shutdown hook to invoke OrderRoutingSystem.stop()

OrderRoutingSystem.stop() invokes SocketInitiator.stop(), which per it's javadoc says that it "Logout existing sessions, close their connections, and stop accepting new connections. "

Did you observe that ORS is not logging out from brokers when it's terminated?

From another angle: Is there a reason why there isn't an interface that exposes the raw fix fields like this? Casting from one class to another seemingly-unrelated class is pretty messy.

The reason Execution Reports do not expose an API to return raw FIX fields is to allow for Execution Reports to come from non-FIX brokers in the future. If an execution report is received from a non-FIX broker, it cannot be interpreted as a FIX Message.

That's why in the current code you have to check if execution report is a FIX report and if it is, get the value of a FIX field.

Henrik,

I filed a request to improve the Strategy API to address the issues that you described in your post.

Could you please look at the request and verify if those improvements will address the issues that you're facing.
Feel free to post comments on the issue with your thoughts.

Cheers,
Anshul

That seems to match what jruby documentation specifies as the default value of LOAD_PATH variable.

If you want to use a ruby library from within your strategy script, you can either copy it to one of the locations listed as the value of LOAD_PATH above or you can change the value of LOAD_PATH as described in the previous posting on this forum.

Interesting use-case:

You probably had to modify the cep-esper module code to access the embedded esper runtime directly. The reason esper statements never get created is because esperio is feeding the events directly to the esper runtime. Since the cep-esper module never sees those events, it never gets the opportunity to create those statements.

In your use-case, since you are accessing the esper runtime directly, I'm curious as to why you are enabling the external time mode for the cep-esper module. You need to enable the external time mode if you want the cep-esper module to automatically handle the esper specifics to deal with external time. In your case, since your code is already handling the external time specifics, it appears to me that you don't really need to enable cep-esper module's external time mode. If you use cep-esper module with external time mode disabled (the default), it will create the CEP statements right when you create a data flow and I'd think, without knowing much about your use-case, that you'll get the behavior you're looking for.

In case you're interested on how the platform can be updated to support the features for this use case, here are my thoughts... If you choose to add these changes to the platform, I'd encourage you to contribute them back.

I can think of following 2 ways to update the platform handle external time when the input data is in CSV format:

Update the CSV module to become 'timestamp' aware and emit a custom Map subclass, that also implements org.marketcetera.event.TimestampCarrier, when the input csv file contains a 'timestamp' column.

Update the cep-esper module to be able to handle 'timestamp' keys when the input data is Map instance and extract the value of that key and send it through as a time event into the esper runtime.

In both of the cases above, we'll have to convert the value from a string to the date-time type. And there are several possibilities here... from a simple interpretation of the string as a long timestamp value to parsing complex date syntax using the SimpleDateFormat.parse().

As far as the coordinated adapter feature goes, a way to get the same effect will be to merge all the csv files together while sorting them on the timestamp column, in excel or via unix command line tools and supplying the merged csv file to the csv module. It shouldn't be too hard to modify the csv module to perform this function either.

Footer Links