Adapter startup differences within StreamBase Studio and from the command-line
Article ID: KB0076045
Updated On:
| Products | Versions |
|---|---|
| TIBCO Streaming | - |
Description
Our EventFlow application runs correctly from the command-line, but when launched in StreamBase Studio's Test/Debug perspective our custom adapter reports an error at startup an fails to run.
What could be the problem?
What could be the problem?
Issue/Introduction
Design guidance
Resolution
The custom adapter is trying to make connections to outside services too early in its startup process. We recommend all external connections be made in the fillAndOutputTuple() method (for input adapters) and the processTuple() method (for output adapters).
At startup, adapter initialization follows these steps:
No connections should be made in the constructor or typecheck() because at startup both are run twice. In SB Studio, the constructor is run whenever a new classloader is needed. The typecheck() method is run frequently to provide feedback on incomplete or incorrect configuration. If a connection were made in these methods, that connection would be disconnected and reconnected frequently with no data flow expected.
The init() method is only run once for the life of the adapter. If a connection is only made in this method, then if that connection is interrupted for any reason, then it cannot be re-established without stopping and restarting the application (or at least the StreamBase container that owns that part of the application).
Waiting until use of the fillAndOutputTuple() and processTuple() methods makes re-connection on an error easy. For fillAndOutputTuple(), at the beginning of the main loop identified by the statement:
while (shouldRun()) {
check the connection object to see if it is 'null' and if so, initiate the connection. When an error occurs set the connection object to 'null' so that a new connection is made when the top of the loop is reached again. This is the fastest way to recover from disconnections. Similarly in processTuple() check whether the connection object is 'null' at the beginning of the method.
The constructor and typecheck() are called multiple times in order to facilitate determining the schemas to be used at runtime and generating the appropriate code to connect one operator to the next. The first call to typecheck() creates the schemas, and the second call validates the properties in the generated Java code for that EventFlow module and adapter.
At startup, adapter initialization follows these steps:
- compilation phase - constructor
- compilation phase - typecheck()
- startup phase - constructor
- startup phase - typecheck()
- startup phase - init()
- running - fillAndOutputTuple() and processTuple()
No connections should be made in the constructor or typecheck() because at startup both are run twice. In SB Studio, the constructor is run whenever a new classloader is needed. The typecheck() method is run frequently to provide feedback on incomplete or incorrect configuration. If a connection were made in these methods, that connection would be disconnected and reconnected frequently with no data flow expected.
The init() method is only run once for the life of the adapter. If a connection is only made in this method, then if that connection is interrupted for any reason, then it cannot be re-established without stopping and restarting the application (or at least the StreamBase container that owns that part of the application).
Waiting until use of the fillAndOutputTuple() and processTuple() methods makes re-connection on an error easy. For fillAndOutputTuple(), at the beginning of the main loop identified by the statement:
while (shouldRun()) {
check the connection object to see if it is 'null' and if so, initiate the connection. When an error occurs set the connection object to 'null' so that a new connection is made when the top of the loop is reached again. This is the fastest way to recover from disconnections. Similarly in processTuple() check whether the connection object is 'null' at the beginning of the method.
The constructor and typecheck() are called multiple times in order to facilitate determining the schemas to be used at runtime and generating the appropriate code to connect one operator to the next. The first call to typecheck() creates the schemas, and the second call validates the properties in the generated Java code for that EventFlow module and adapter.
Feedback
Yes
No
Powered by
