quickfixj-users — General mailing list for QuickFIX/J topics.

Re: [Quickfixj-users] repeating group problem

[Alvin W. <AW...@FF...>]

I tried to use "new Group(field, delim, new int[] { delim })" that you
recommended, in QF's Java wrapper, I got an crash as below:

=================================================================
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at
PC=0x75BF1DA
Function=[Unknown.]
Library=C:\dev\quickfix\lib\quickfix_jni.dll

NOTE: We are unable to locate the function name symbol for the error
      just occurred. Please refer to release documentation for possible
      reason and solutions.


Current Java thread:
      at quickfix.Group.create(Native Method)
      at quickfix.Group.<init>(Unknown Source)
......

Dynamic libraries:
0x00400000 - 0x00407000       C:\JBuilderX\jdk1.4\bin\javaw.exe
0x7C900000 - 0x7C9B0000       C:\WINDOWS\system32\ntdll.dll
0x7C800000 - 0x7C8F4000       C:\WINDOWS\system32\kernel32.dll
0x77DD0000 - 0x77E6B000       C:\WINDOWS\system32\ADVAPI32.dll
0x77E70000 - 0x77F01000       C:\WINDOWS\system32\RPCRT4.dll
0x77D40000 - 0x77DD0000       C:\WINDOWS\system32\USER32.dll
0x77F10000 - 0x77F57000       C:\WINDOWS\system32\GDI32.dll
0x77C10000 - 0x77C68000       C:\WINDOWS\system32\MSVCRT.dll
0x76390000 - 0x763AD000       C:\WINDOWS\system32\IMM32.DLL
0x629C0000 - 0x629C9000       C:\WINDOWS\system32\LPK.DLL
0x74D90000 - 0x74DFB000       C:\WINDOWS\system32\USP10.dll
0x08000000 - 0x08136000       C:\JBuilderX\jdk1.4\jre\bin\client\jvm.dll
0x76B40000 - 0x76B6D000       C:\WINDOWS\system32\WINMM.dll
0x10000000 - 0x10007000       C:\JBuilderX\jdk1.4\jre\bin\hpi.dll
0x00940000 - 0x0094E000       C:\JBuilderX\jdk1.4\jre\bin\verify.dll
0x00950000 - 0x00968000       C:\JBuilderX\jdk1.4\jre\bin\java.dll
0x00970000 - 0x0097D000       C:\JBuilderX\jdk1.4\jre\bin\zip.dll
0x02C60000 - 0x02C7C000       C:\JBuilderX\jdk1.4\jre\bin\jdwp.dll
0x06C80000 - 0x06C85000       C:\JBuilderX\jdk1.4\jre\bin\dt_socket.dll
0x71AB0000 - 0x71AC7000       C:\WINDOWS\system32\ws2_32.dll
0x71AA0000 - 0x71AA8000       C:\WINDOWS\system32\WS2HELP.dll
0x71A50000 - 0x71A8F000       C:\WINDOWS\System32\mswsock.dll
0x76F20000 - 0x76F47000       C:\WINDOWS\system32\DNSAPI.dll
0x76FB0000 - 0x76FB8000       C:\WINDOWS\System32\winrnr.dll
0x76F60000 - 0x76F8C000       C:\WINDOWS\system32\WLDAP32.dll
0x76FC0000 - 0x76FC6000       C:\WINDOWS\system32\rasadhlp.dll
0x662B0000 - 0x66308000       C:\WINDOWS\system32\hnetcfg.dll
0x71A90000 - 0x71A98000       C:\WINDOWS\System32\wshtcpip.dll
0x07520000 - 0x07664000       C:\dev\quickfix\lib\quickfix_jni.dll
0x774E0000 - 0x7761D000       C:\WINDOWS\system32\ole32.dll
0x77120000 - 0x771AC000       C:\WINDOWS\system32\OLEAUT32.dll
0x76080000 - 0x760E5000       C:\WINDOWS\system32\MSVCP60.dll
0x07670000 - 0x07778000       C:\dev\quickfix\lib\LIBMYSQL.dll
0x71AD0000 - 0x71AD9000       C:\WINDOWS\system32\WSOCK32.dll
0x76FD0000 - 0x7704F000       C:\WINDOWS\system32\CLBCATQ.DLL
0x77050000 - 0x77115000       C:\WINDOWS\system32\COMRes.dll
0x77C00000 - 0x77C08000       C:\WINDOWS\system32\VERSION.dll
0x07AA0000 - 0x07AAF000       C:\JBuilderX\jdk1.4\jre\bin\net.dll
0x07AB0000 - 0x07AB8000       C:\JBuilderX\jdk1.4\jre\bin\nio.dll
0x07FE0000 - 0x07FE5000       C:\JBuilderX\jdk1.4\jre\bin\rmi.dll
0x77B40000 - 0x77B62000       C:\WINDOWS\system32\Apphelp.dll
0x76C90000 - 0x76CB8000       C:\WINDOWS\system32\imagehlp.dll
0x59A60000 - 0x59B01000       C:\WINDOWS\system32\DBGHELP.dll
0x76BF0000 - 0x76BFB000       C:\WINDOWS\system32\PSAPI.DLL

Heap at VM Abort:
Heap
 def new generation   total 576K, used 124K [0x10010000, 0x100b0000,
0x104f0000)
  eden space 512K,  22% used [0x10010000, 0x1002cfd0, 0x10090000)
  from space 64K,  12% used [0x100a0000, 0x100a20d0, 0x100b0000)
  to   space 64K,   0% used [0x10090000, 0x10090000, 0x100a0000)
 tenured generation   total 2028K, used 1350K [0x104f0000, 0x106eb000,
0x14010000)
   the space 2028K,  66% used [0x104f0000, 0x10641aa0, 0x10641c00,
0x106eb000)
 compacting perm gen  total 12288K, used 12134K [0x14010000, 0x14c10000,
0x18010000)
   the space 12288K,  98% used [0x14010000, 0x14be9aa0, 0x14be9c00,
0x14c10000)

Local Time = Fri Nov 10 09:45:37 2006
Elapsed Time = 571
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_01-b06 mixed mode)
#
# An error report file has been saved as hs_err_pid4488.log.
# Please refer to the file for further information.
#




                                                                           
             "Steve Bate"                                                  
             <steve@technoetic                                             
             .com>                                                      To 
             Sent by:                  <qui...@li.... 
             quickfixj-users-b         net>                                
             ou...@li...                                          cc 
             ceforge.net                                                   
                                                                   Subject 
                                       Re: [Quickfixj-users] repeating     
             11/07/2006 08:28          group problem                       
             PM                                                            
                                                                           
                                                                           
             Please respond to                                             
             quickfixj-users@l                                             
             ists.sourceforge.                                             
                    net                                                    
                                                                           
                                                                           



QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/
> The reason I do not want to use NewOrderSingle.NoPartyIDs is that my
order
> object can be either a NewOrderSingle or NewOrderMultileg. Not sure if I
> can add a NewOrderSingle.NoPartyIDs  object to a NewOrderMultileg object?
> Could you clarify? Just wonder why there is not an abstract class sitting
> on the top like GeneralOrder which can enclose some common fields or
> classes like NoPartyIDs?

The messages correspond directly to the FIX specification.

You don't necessarily need a new build. Have you tried using the
Group(int field, int delim, int[] order) constructor in 1.0.4?
The only change I made was to make Group(field, delim) call
Group(field, delim, new int[] { delim }). Better yet, you'll
be safer if you include all the tags in the integer array in
the correct order. However, like Oren said, many FIX engines
will not enforce the order of the non-delimeter tags.

Steve



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Quickfixj-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfixj-users




                                                                *******************************************************************************
This e-mail message is intended solely for the use of the addressee.
The message may contain information that is privileged and 
confidential.
Disclosure to anyone other than the intended recipient is prohibited.
If you are not the intended recipient, please do not disseminate,
distribute or copy this communication, by e-mail or otherwise. Instead,
please notify us immediately by return e-mail(including the original
message with your reply) and then delete and discard all copies of the
message. We have taken precautions to minimize the risk of  transmitting
software viruses but nevertheless advise you to carry out your own
virus checks on any attachment to this message.  We accept
no liability for any loss or damage caused by software viruses.
*******************************************************************************

Re: [Quickfixj-users] repeating group problem

[Steve B. <st...@te...>]

> Yes, the messages are decoupled, the fields are not.  It's not really
> been much of a problem though since when using non typesafe methods
> the messages don't care what the field is as long as the number and
> type are correct.  I guess it is conceivable future versions of fix
> could change the names or types of the core session fields, but I
> don't think it's very likely.   Theoretically this could be decoupled
> as well, though if any of those fields are missing you don't really
> have a FIX session anymore.  Perhaps that would be a legitimate thing
> to do if you plan on using another transport as made possible by FIX
> 5.0.

I'm exploring the possibility of packaged message representations
for various flavors of FIX. The existing generated representations
would be just one option. I'm also thinking it would be an option to 
use the generic messages without any code generation at all.

>...
> > My impression was that Alvin didn't want to give up all type safety,
> > but wanted a message representation with more abstractions for common
> > aspects of the currently generated message classes. Personally, I
> > would just use the message objects directly as you've suggested.
> 
> Yeah, I think so to, I'm just not sure how that would be
> accomplished.  Perhaps an example would be helpful.  The problem is
> of course that messages change pretty significantly between versions
> sometimes.  Fields get added, removed, their type changes, groups are
> added, groups are modified etc. etc.

Examples of message overlap are the NewOrderSingle and NewOrderList.
Although that could be extracted to a common base class, I agree with
you that it would probably be too much work to develop and maintain.

Steve

Re: [Quickfixj-users] repeating group problem

[Brad H. <Bra...@gb...>]

Hi,

Perhaps part of the problem is that the User Manual has some notes on
type safety and strongly encourages you to use the "Most Type Safe"
method of doing things which relies on the generated classes.  As you
say, to support multiple FIX versions you can't really do that - you
have to use the "More Type Safe" (or lower) method.

This means the message cracker isn't very useful for receiving messages
- if you want common code for each version you'll be casting back to
quickfix.Message anyway.  We don't use the message cracker in our
quickfix/j app, but rather code like this:

	Header header =3D message.getHeader();
	String msgType =3D header.getString(MsgType.FIELD);
	if (MsgType.EXECUTION_REPORT.equals(msgType)) {
		if (message.isSetField(ExecType.FIELD)) {
			String executionType =3D
message.getString(ExecType.FIELD);
      ....

>From memory the message cracker does something similar to switch on
version/message type anyway and then just casts to the appropriate type.


What this doesn't give you is any compile time validation/auto complete
for what fields are in your message, but use of the fields names at
least gives you readability.  Good unit tests on your domain <->
quickfix mapping can help make up for the loss of compile time safety.

Unfortunately you pretty much have to use the generated group classes
for repeating groups.  I think the factory approach discussed earlier
would be a good compromise, and the underlying implementation (inner
classes vs component objects or whatever) wouldn't really matter.=20

Cheers,
Brad.

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of Oren
Miller
Sent: Friday, 10 November 2006 8:40 AM
To: qui...@li...
Subject: Re: [Quickfixj-users] repeating group problem

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/
Isn't the session code already decoupled from the generated message =20
code?  It has been that way with QuickFIX since the beginning.  Is =20
this different in QuickFIX/J?

The purpose of the generated classes is to allow you to add a certain =20
level of type safety by taking advantage of the compilers type =20
system.  If you are are writing code that supports multiple versions =20
(is there a reason for this?  Are you using the fix messages as your =20
domain objects instead of converting them at the edge of your =20
system?), you do not want type safety.  I'm not sure it really makes =20
sense.  At least in QuickFIX, the Session class is an example of an =20
object that supports multiple versions of fix which does not make use =20
of type safety.  No generated message classes are used anywhere in =20
there.

If you are trying to write code blocks to support multiple versions, =20
you should be working directly with the Message class.  I'm not sure =20
how the generated objects help you at all since type safety is not =20
something you desire in this case.  Is there something I'm missing?

--oren

Re: [Quickfixj-users] repeating group problem

[Oren M. <or...@qu...>]

> I believe QFJ is only dependent on generated field definitions. Do you
> manually maintain the C++/Fields.h file? Is that where the C++ Session
> gets it's field definitions rather than the generated field  
> definitions?

Yes, the messages are decoupled, the fields are not.  It's not really  
been much of a problem though since when using non typesafe methods  
the messages don't care what the field is as long as the number and  
type are correct.  I guess it is conceivable future versions of fix  
could change the names or types of the core session fields, but I  
don't think it's very likely.   Theoretically this could be decoupled  
as well, though if any of those fields are missing you don't really  
have a FIX session anymore.  Perhaps that would be a legitimate thing  
to do if you plan on using another transport as made possible by FIX  
5.0.

> I can't speak for Alvin, but I've been in several situations where
> I've needed to map domain objects to multiple versions of FIX
> and vice versa.

Oh yeah, me too.  In those situations there's a choice about whether  
to use compile time type safety or use dynamic logic.  Using type  
safety requires some more coding, but you have the benefits of the  
compiler letting you know when something is wrong.  Dynamic code  
doesn't give you that, but it allows you to create more compact code  
by allowing you to share.  I'm not really sure how you can get both  
those benefits at the same time.  Classic case of dynamic vs compile  
time type safety.

> My impression was that Alvin didn't want to give up all type safety,
> but wanted a message representation with more abstractions for common
> aspects of the currently generated message classes. Personally, I
> would just use the message objects directly as you've suggested.

Yeah, I think so to, I'm just not sure how that would be  
accomplished.  Perhaps an example would be helpful.  The problem is  
of course that messages change pretty significantly between versions  
sometimes.  Fields get added, removed, their type changes, groups are  
added, groups are modified etc. etc.

Groups are actually a case where you can take advantage of some  
sharing.  If groups have not significantly changed between versions,  
their is no reason you cannot call addGroup on a FIX.4.2 messages or  
a FIX.4.4 message with the same generated group object.  Making  
components into objects might be helpful in this regard as well.

Re: [Quickfixj-users] Adding qualifier to quickfix Message

[Oren M. <or...@qu...>]

Whatever the case concerning the academics various FIX ids, I agree  
with this approach.

--oren

> A possible approach would be to support subId and locationId as
> identification fields if they are specified in the session settings.
> Otherwise, those fields would be ignored for routing purposes (party-
> to-party or third-party) and just passed to the application.
>
> Steve

Re: [Quickfixj-users] Adding qualifier to quickfix Message

[<st...@te...>]

> Yes.  The only reason the qualifier was added is because of a counter
> party that had different subsystems that were only differentiated by
> connectivity and otherwise share identical session identification.  I
> would not recommend ever using it unless a counterparty forces you
> into the situation and is too stubborn to do anything about it.  It
> is intended strictly as an internal identifier.
>
> I'm not really sure how SubID and LocationID solve the same problem
> as they don't do anything to uniquely identify a session since
> multiple subid and locationid combinations can be sent through a
> session.

Do you have pointers in the spec related to this? The thirdparty
routing fields seem to imply that the subId and locationId can
be used for routing at the session protocol level. The session
protocol would only know how to route between sessions so it seemed
to me that subId and locationId were being used as optional parts
of a session identifier. I agree there is nothing to prohibit using
those fields for application level purposes as well although
the fields are defined as part of the session protocol. My experience
has been that counterparties used them for session identification
purposes but I know there are many variations of FIX usage.

> In this case, however, subids are the appropriate solution.

A possible approach would be to support subId and locationId as
identification fields if they are specified in the session settings.
Otherwise, those fields would be ignored for routing purposes (party-
to-party or third-party) and just passed to the application.

Steve

Re: [Quickfixj-users] repeating group problem

[<st...@te...>]

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
> Isn't the session code already decoupled from the generated message
> code?  It has been that way with QuickFIX since the beginning.  Is
> this different in QuickFIX/J?

I believe QFJ is only dependent on generated field definitions. Do you
manually maintain the C++/Fields.h file? Is that where the C++ Session
gets it's field definitions rather than the generated field definitions?

> The purpose of the generated classes is to allow you to add a certain
> level of type safety by taking advantage of the compilers type
> system.  If you are are writing code that supports multiple versions
> (is there a reason for this?  Are you using the fix messages as your
> domain objects instead of converting them at the edge of your
> system?), you do not want type safety.

I can't speak for Alvin, but I've been in several situations where
I've needed to map domain objects to multiple versions of FIX
and vice versa.

> I'm not sure it really makes
> sense.  At least in QuickFIX, the Session class is an example of an
> object that supports multiple versions of fix which does not make use
> of type safety.  No generated message classes are used anywhere in
> there.

Again, that's mostly true for QFJ also.

> If you are trying to write code blocks to support multiple versions,
> you should be working directly with the Message class.  I'm not sure
> how the generated objects help you at all since type safety is not
> something you desire in this case.  Is there something I'm missing?

My impression was that Alvin didn't want to give up all type safety,
but wanted a message representation with more abstractions for common
aspects of the currently generated message classes. Personally, I
would just use the message objects directly as you've suggested.

Steve

> On Nov 8, 2006, at 11:02 AM, st...@te... wrote:
>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>> Hi Alvin,
>>
>> I understand and I tend to agree. However, I'd like to hear Oren's
>> comments on these issues. The core QFJ API is based on the QF API
>> and it's our goal to keep them compatible when moving from QF to QFJ.
>>
>> That said, one of the features being planned for a post 1.1.0
>> release is to completely decouple the session protocol engine
>> from the generated message/field code. This will give increased
>> flexibility for packaging and using custom message representations
>> although they must still be based on quickfix.Message. For example,
>> we intend to provide a message representation that uses BigDecimal
>> for prices and other values that need precise representations.
>> ...

Re: [Quickfixj-users] Adding qualifier to quickfix Message

[Oren M. <or...@qu...>]

Yes.  The only reason the qualifier was added is because of a counter  
party that had different subsystems that were only differentiated by  
connectivity and otherwise share identical session identification.  I  
would not recommend ever using it unless a counterparty forces you  
into the situation and is too stubborn to do anything about it.  It  
is intended strictly as an internal identifier.

I'm not really sure how SubID and LocationID solve the same problem  
as they don't do anything to uniquely identify a session since  
multiple subid and locationid combinations can be sent through a  
session.

In this case, however, subids are the appropriate solution.

--oren

On Nov 8, 2006, at 2:33 PM, st...@te... wrote:

> I don't mind making the setSessionID method to be public. Adding  
> methods
> to the QFJ classes doesn't break compatibility from QF to QFJ.
>
> However, I'd recommend not using the qualifier. Other than for
> compatibility I'd not have it in the code at all. I'd rather identify
> sessions by standard compID, subID, and locationID. This is another  
> future
> change on my list, although I can't remove session qualifier without
> breaking QF compatibility. The use of session qualifier also makes it
> difficult or impossible to support standard third party routing in the
> session protocol engine because there is no standard message field  
> defined
> for the qualifier (qualifiers can't be /sent/ to a counterparty in any
> standard way). In other words, it's not part of the protocol. It's  
> a trick
> to handle a situation where a counterparty wants to have two  
> simultaneous
> sessions with the same protocol-level identification.
>
> As you may have guessed, I'm not inclined to add more support for  
> session
> qualifier. :-) However, I'm open to more discussion.
>
> Regards,
>
> Steve
>
> Steve
>
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>

Re: [Quickfixj-users] repeating group problem

[Oren M. <or...@qu...>]

Isn't the session code already decoupled from the generated message  
code?  It has been that way with QuickFIX since the beginning.  Is  
this different in QuickFIX/J?

The purpose of the generated classes is to allow you to add a certain  
level of type safety by taking advantage of the compilers type  
system.  If you are are writing code that supports multiple versions  
(is there a reason for this?  Are you using the fix messages as your  
domain objects instead of converting them at the edge of your  
system?), you do not want type safety.  I'm not sure it really makes  
sense.  At least in QuickFIX, the Session class is an example of an  
object that supports multiple versions of fix which does not make use  
of type safety.  No generated message classes are used anywhere in  
there.

If you are trying to write code blocks to support multiple versions,  
you should be working directly with the Message class.  I'm not sure  
how the generated objects help you at all since type safety is not  
something you desire in this case.  Is there something I'm missing?

--oren

On Nov 8, 2006, at 11:02 AM, st...@te... wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
> Hi Alvin,
>
> I understand and I tend to agree. However, I'd like to hear Oren's
> comments on these issues. The core QFJ API is based on the QF API
> and it's our goal to keep them compatible when moving from QF to QFJ.
>
> That said, one of the features being planned for a post 1.1.0
> release is to completely decouple the session protocol engine
> from the generated message/field code. This will give increased
> flexibility for packaging and using custom message representations
> although they must still be based on quickfix.Message. For example,
> we intend to provide a message representation that uses BigDecimal
> for prices and other values that need precise representations.
>
> My long term vision is to redesign the parsing engine to allow
> mapping of FIX messages directly to POJOs that aren't required to
> inherit from quickfix.Message at all. I'm not sure when I'll have
> time to do that since QFJ is a spare time project for me. ;-)
>
> Steve
>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>> I understand that the classes are generated automatically from  
>> XML. But I
>> feel it may be better to have some optimization and abstractions.  
>> This
>> will
>> greatly improve code reusibility and flexibility, for example codes
>> handling different order messages and even different FIX versions.  
>> How to
>> easily maintain the code base when we need to handle different  
>> versions of
>> FIX is always our concern by using QF or QF/J. Right now, the message
>> classes are bounded with FIX version. Any insights?
>>
>> Just my 2 cents
>>
>>
>>
>>
>>              "Steve Bate"
>>              <steve@technoetic
>>              .com>                                                    
>>    To
>>              Sent by:                  <quickfixj- 
>> us...@li....
>>              quickfixj-users-b         net>
>>               
>> ou...@li...                                          cc
>>              ceforge.net
>>                                                                     
>> Subject
>>                                        Re: [Quickfixj-users]  
>> repeating
>>              11/07/2006 08:28          group problem
>>              PM
>>
>>
>>              Please respond to
>>              quickfixj-users@l
>>              ists.sourceforge.
>>                     net
>>
>>
>>
>>
>>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>> The reason I do not want to use NewOrderSingle.NoPartyIDs is that my
>> order
>>> object can be either a NewOrderSingle or NewOrderMultileg. Not  
>>> sure if I
>>> can add a NewOrderSingle.NoPartyIDs  object to a NewOrderMultileg
>>> object?
>>> Could you clarify? Just wonder why there is not an abstract class
>>> sitting
>>> on the top like GeneralOrder which can enclose some common fields or
>>> classes like NoPartyIDs?
>>
>> The messages correspond directly to the FIX specification.
>>
>> You don't necessarily need a new build. Have you tried using the
>> Group(int field, int delim, int[] order) constructor in 1.0.4?
>> The only change I made was to make Group(field, delim) call
>> Group(field, delim, new int[] { delim }). Better yet, you'll
>> be safer if you include all the tags in the integer array in
>> the correct order. However, like Oren said, many FIX engines
>> will not enforce the order of the non-delimeter tags.
>>
>> Steve
>>
>>
>>
>> --------------------------------------------------------------------- 
>> ----
>> Using Tomcat but need to do more? Need to support web services,  
>> security?
>> Get stuff done quickly with pre-integrated technology to make your  
>> job
>> easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
>> Geronimo
>> http://sel.as-us.falkag.net/sel? 
>> cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> Quickfixj-users mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>>
>>
>>
>>                                                                  
>> ********************************************************************* 
>> **********
>> This e-mail message is intended solely for the use of the addressee.
>> The message may contain information that is privileged and
>> confidential.
>> Disclosure to anyone other than the intended recipient is prohibited.
>> If you are not the intended recipient, please do not disseminate,
>> distribute or copy this communication, by e-mail or otherwise.  
>> Instead,
>> please notify us immediately by return e-mail(including the original
>> message with your reply) and then delete and discard all copies of  
>> the
>> message. We have taken precautions to minimize the risk of   
>> transmitting
>> software viruses but nevertheless advise you to carry out your own
>> virus checks on any attachment to this message.  We accept
>> no liability for any loss or damage caused by software viruses.
>> ********************************************************************* 
>> **********
>>
>>
>>
>> --------------------------------------------------------------------- 
>> ----
>> Using Tomcat but need to do more? Need to support web services,  
>> security?
>> Get stuff done quickly with pre-integrated technology to make your  
>> job
>> easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
>> Geronimo
>> http://sel.as-us.falkag.net/sel? 
>> cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> Quickfixj-users mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>
>
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>

Re: [Quickfixj-users] Adding qualifier to quickfix Message

[Brad H. <Bra...@gb...>]

Hi Toli,

To avoid API changes you could wrap your FIX Message in an object that
has some sort of header for routing info, and a payload for the actual
FIX message.  I'm envisaging something similar to JMS messages. =20

Cheers,
Brad.=20

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of Toli
Kuznets
Sent: Thursday, 9 November 2006 5:47 AM
To: qui...@li...
Subject: [Quickfixj-users] Adding qualifier to quickfix Message

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/
Hey guys,

Wanted to ask for advice on the best way to decouple the business
logic from sending logic in quickfixj.

For example, we are trying to use a messaging framework where our
"OrderManager" would drop a completely configured FIX message on a
queue that will then be sent out by another thread.

To send the message, we need to have the FIX message configured with
all the sessionID routing info (sender/targetIDs + beginString +
qualifier).

However, currently it's not possible to set the qualifier on the
Message object itself - there's no setter for that, and we don't want
to invent a custom FIX field to store it in the message itself either.

What would you recommend the best approach to solve this?
A change to the API (adding quickfix.Message.setQualifier() and
changing quickfix.Message.setSessionID to be public instead of
package-protected) would solve our problem, but it's a change to the
API and i'm not sure it's the best approach.

any other ideas/advice?

thanks!

--=20
Toli Kuznets
http://www.marketcetera.com: Open-Source Trading Platform
download.run.trade.

------------------------------------------------------------------------
-
Using Tomcat but need to do more? Need to support web services,
security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
121642
_______________________________________________
Quickfixj-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

Re: [Quickfixj-users] Adding qualifier to quickfix Message

[<st...@te...>]

> Wanted to ask for advice on the best way to decouple the business
> logic from sending logic in quickfixj.
>
> For example, we are trying to use a messaging framework where our
> "OrderManager" would drop a completely configured FIX message on a
> queue that will then be sent out by another thread.
>
> To send the message, we need to have the FIX message configured with
> all the sessionID routing info (sender/targetIDs + beginString +
> qualifier).
>
> However, currently it's not possible to set the qualifier on the
> Message object itself - there's no setter for that, and we don't want
> to invent a custom FIX field to store it in the message itself either.
>
> What would you recommend the best approach to solve this?
> A change to the API (adding quickfix.Message.setQualifier() and
> changing quickfix.Message.setSessionID to be public instead of
> package-protected) would solve our problem, but it's a change to the
> API and i'm not sure it's the best approach.

I don't mind making the setSessionID method to be public. Adding methods
to the QFJ classes doesn't break compatibility from QF to QFJ.

However, I'd recommend not using the qualifier. Other than for
compatibility I'd not have it in the code at all. I'd rather identify
sessions by standard compID, subID, and locationID. This is another future
change on my list, although I can't remove session qualifier without
breaking QF compatibility. The use of session qualifier also makes it
difficult or impossible to support standard third party routing in the
session protocol engine because there is no standard message field defined
for the qualifier (qualifiers can't be /sent/ to a counterparty in any
standard way). In other words, it's not part of the protocol. It's a trick
to handle a situation where a counterparty wants to have two simultaneous
sessions with the same protocol-level identification.

As you may have guessed, I'm not inclined to add more support for session
qualifier. :-) However, I'm open to more discussion.

Regards,

Steve

Steve

[Quickfixj-users] Adding qualifier to quickfix Message

[Toli K. <to...@ma...>]

Hey guys,

Wanted to ask for advice on the best way to decouple the business
logic from sending logic in quickfixj.

For example, we are trying to use a messaging framework where our
"OrderManager" would drop a completely configured FIX message on a
queue that will then be sent out by another thread.

To send the message, we need to have the FIX message configured with
all the sessionID routing info (sender/targetIDs + beginString +
qualifier).

However, currently it's not possible to set the qualifier on the
Message object itself - there's no setter for that, and we don't want
to invent a custom FIX field to store it in the message itself either.

What would you recommend the best approach to solve this?
A change to the API (adding quickfix.Message.setQualifier() and
changing quickfix.Message.setSessionID to be public instead of
package-protected) would solve our problem, but it's a change to the
API and i'm not sure it's the best approach.

any other ideas/advice?

thanks!

-- 
Toli Kuznets
http://www.marketcetera.com: Open-Source Trading Platform
download.run.trade.

Re: [Quickfixj-users] repeating group problem

[<st...@te...>]

Hi Alvin,

I understand and I tend to agree. However, I'd like to hear Oren's
comments on these issues. The core QFJ API is based on the QF API
and it's our goal to keep them compatible when moving from QF to QFJ.

That said, one of the features being planned for a post 1.1.0
release is to completely decouple the session protocol engine
from the generated message/field code. This will give increased
flexibility for packaging and using custom message representations
although they must still be based on quickfix.Message. For example,
we intend to provide a message representation that uses BigDecimal
for prices and other values that need precise representations.

My long term vision is to redesign the parsing engine to allow
mapping of FIX messages directly to POJOs that aren't required to
inherit from quickfix.Message at all. I'm not sure when I'll have
time to do that since QFJ is a spare time project for me. ;-)

Steve

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
> I understand that the classes are generated automatically from XML. But I
> feel it may be better to have some optimization and abstractions. This
> will
> greatly improve code reusibility and flexibility, for example codes
> handling different order messages and even different FIX versions. How to
> easily maintain the code base when we need to handle different versions of
> FIX is always our concern by using QF or QF/J. Right now, the message
> classes are bounded with FIX version. Any insights?
>
> Just my 2 cents
>
>
>
>
>              "Steve Bate"
>              <steve@technoetic
>              .com>                                                      To
>              Sent by:                  <qui...@li....
>              quickfixj-users-b         net>
>              ou...@li...                                          cc
>              ceforge.net
>                                                                    Subject
>                                        Re: [Quickfixj-users] repeating
>              11/07/2006 08:28          group problem
>              PM
>
>
>              Please respond to
>              quickfixj-users@l
>              ists.sourceforge.
>                     net
>
>
>
>
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>> The reason I do not want to use NewOrderSingle.NoPartyIDs is that my
> order
>> object can be either a NewOrderSingle or NewOrderMultileg. Not sure if I
>> can add a NewOrderSingle.NoPartyIDs  object to a NewOrderMultileg
>> object?
>> Could you clarify? Just wonder why there is not an abstract class
>> sitting
>> on the top like GeneralOrder which can enclose some common fields or
>> classes like NoPartyIDs?
>
> The messages correspond directly to the FIX specification.
>
> You don't necessarily need a new build. Have you tried using the
> Group(int field, int delim, int[] order) constructor in 1.0.4?
> The only change I made was to make Group(field, delim) call
> Group(field, delim, new int[] { delim }). Better yet, you'll
> be safer if you include all the tags in the integer array in
> the correct order. However, like Oren said, many FIX engines
> will not enforce the order of the non-delimeter tags.
>
> Steve
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>
>
>
>                                                                 *******************************************************************************
> This e-mail message is intended solely for the use of the addressee.
> The message may contain information that is privileged and
> confidential.
> Disclosure to anyone other than the intended recipient is prohibited.
> If you are not the intended recipient, please do not disseminate,
> distribute or copy this communication, by e-mail or otherwise. Instead,
> please notify us immediately by return e-mail(including the original
> message with your reply) and then delete and discard all copies of the
> message. We have taken precautions to minimize the risk of  transmitting
> software viruses but nevertheless advise you to carry out your own
> virus checks on any attachment to this message.  We accept
> no liability for any loss or damage caused by software viruses.
> *******************************************************************************
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>

Re: [Quickfixj-users] repeating group problem

[Alvin W. <AW...@FF...>]

I understand that the classes are generated automatically from XML. But I
feel it may be better to have some optimization and abstractions. This will
greatly improve code reusibility and flexibility, for example codes
handling different order messages and even different FIX versions. How to
easily maintain the code base when we need to handle different versions of
FIX is always our concern by using QF or QF/J. Right now, the message
classes are bounded with FIX version. Any insights?

Just my 2 cents



                                                                           
             "Steve Bate"                                                  
             <steve@technoetic                                             
             .com>                                                      To 
             Sent by:                  <qui...@li.... 
             quickfixj-users-b         net>                                
             ou...@li...                                          cc 
             ceforge.net                                                   
                                                                   Subject 
                                       Re: [Quickfixj-users] repeating     
             11/07/2006 08:28          group problem                       
             PM                                                            
                                                                           
                                                                           
             Please respond to                                             
             quickfixj-users@l                                             
             ists.sourceforge.                                             
                    net                                                    
                                                                           
                                                                           



QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/
> The reason I do not want to use NewOrderSingle.NoPartyIDs is that my
order
> object can be either a NewOrderSingle or NewOrderMultileg. Not sure if I
> can add a NewOrderSingle.NoPartyIDs  object to a NewOrderMultileg object?
> Could you clarify? Just wonder why there is not an abstract class sitting
> on the top like GeneralOrder which can enclose some common fields or
> classes like NoPartyIDs?

The messages correspond directly to the FIX specification.

You don't necessarily need a new build. Have you tried using the
Group(int field, int delim, int[] order) constructor in 1.0.4?
The only change I made was to make Group(field, delim) call
Group(field, delim, new int[] { delim }). Better yet, you'll
be safer if you include all the tags in the integer array in
the correct order. However, like Oren said, many FIX engines
will not enforce the order of the non-delimeter tags.

Steve



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Quickfixj-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfixj-users




                                                                *******************************************************************************
This e-mail message is intended solely for the use of the addressee.
The message may contain information that is privileged and 
confidential.
Disclosure to anyone other than the intended recipient is prohibited.
If you are not the intended recipient, please do not disseminate,
distribute or copy this communication, by e-mail or otherwise. Instead,
please notify us immediately by return e-mail(including the original
message with your reply) and then delete and discard all copies of the
message. We have taken precautions to minimize the risk of  transmitting
software viruses but nevertheless advise you to carry out your own
virus checks on any attachment to this message.  We accept
no liability for any loss or damage caused by software viruses.
*******************************************************************************

Re: [Quickfixj-users] repeating group problem

[Steve B. <st...@te...>]

> The reason I do not want to use NewOrderSingle.NoPartyIDs is that my order
> object can be either a NewOrderSingle or NewOrderMultileg. Not sure if I
> can add a NewOrderSingle.NoPartyIDs  object to a NewOrderMultileg object?
> Could you clarify? Just wonder why there is not an abstract class sitting
> on the top like GeneralOrder which can enclose some common fields or
> classes like NoPartyIDs?

The messages correspond directly to the FIX specification.

You don't necessarily need a new build. Have you tried using the
Group(int field, int delim, int[] order) constructor in 1.0.4?
The only change I made was to make Group(field, delim) call
Group(field, delim, new int[] { delim }). Better yet, you'll
be safer if you include all the tags in the integer array in
the correct order. However, like Oren said, many FIX engines
will not enforce the order of the non-delimeter tags.

Steve

Re: [Quickfixj-users] repeating group problem

[Toli K. <to...@ma...>]

Alvin,

Don't have the answers to your repeating groups question, but if you
want to get the HEAD of the quickfixj tree, follow the instructions
here:
http://sourceforge.net/svn/?group_id=163099

Essentially, you need to install SVN if you don't have it and run this command:
%>  svn co https://svn.sourceforge.net/svnroot/quickfixj/trunk quickfixj-latest

and you'll have the latest source code branch.

the source code is under code/ subdirectory.

On 11/7/06, Alvin Wang <AW...@ff...> wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
> Steve,
>
> The reason I do not want to use NewOrderSingle.NoPartyIDs is that my order
> object can be either a NewOrderSingle or NewOrderMultileg. Not sure if I
> can add a NewOrderSingle.NoPartyIDs  object to a NewOrderMultileg object?
> Could you clarify? Just wonder why there is not an abstract class sitting
> on the top like GeneralOrder which can enclose some common fields or
> classes like NoPartyIDs?
>
> BTW, could you tell me how I can get the latest build if you have some new
> fixes?
>
> thanks
>
>
>
>
>
>
>
>              "Steve Bate"
>              <steve@technoetic
>              .com>                                                      To
>              Sent by:                  <qui...@li....
>              quickfixj-users-b         net>
>              ou...@li...                                          cc
>              ceforge.net
>                                                                    Subject
>                                        Re: [Quickfixj-users] repeating
>              11/03/2006 09:49          group problem
>              PM
>
>
>              Please respond to
>              quickfixj-users@l
>              ists.sourceforge.
>                     net
>
>
>
>
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
> Alvin,
>
> I recommend using the NewOrderSingle.NoPartyIDs rather than the
> generic Group. The C++ code does create an ordering for the delimeter
> field using the constructor you're using and QFJ does not. We can
> change tnat behavior to be consistent with the C++ constructor but
> this usage of the generic Group will be dangerous to use in both C++ and
> QFJ. The C++ code happens to order the non-delimeter fields in key order,
> which are tag numbers in this case. You are fortunate to have two
> non-delimeter tags where the tag number ordering and the group field
> ordering are the same. In general, you probably wouldn't be so lucky
> since the ordering of the non-delimeter fields is undefined from an
> API perspective when using this Group constructor.
>
> If users want to create a generic Group rather than using the
> message-specific groups we should probably create a constructor that
> takes a group field tag number and a data dictionary and let the
> constructor build the correct ordering criteria and determine the
> delimeter field from the dictionary. It seems safer.
>
> Oren, any comments?
>
> Steve
>
> -----Original Message-----
> From: Alvin Wang [mailto:AW...@FF...]
> Sent: Friday, November 03, 2006 2:22 PM
> To: qui...@li...
> Cc: qui...@li...;
> qui...@li...
> Subject: repeating group problem
>
>         Group partyGroup = new Group(NoPartyIDs.FIELD, PartyID.FIELD);
>         partyGroup.setField(new PartyID("TraderName"));
>         partyGroup.setField(new
> PartyIDSource(PartyIDSource.GENERALLY_ACCEPTED_MARKET_PARTICIPANT_IDENTIFIER
>
> ));
>         partyGroup.setField(new PartyRole(11));
>         order.addGroup(partyGroup);
>
> We suspect that Quickfix/J does not create the right order, while QF's java
> wrapper can with the same code above.
>
> Quickfix/J:
> 453=1|447=C|448=TraderName|452=11     (448 should be the group delimiter)
>
> QF's Java:
> 453=1|448=TraderName|447=C|452=11
>
> Pls take a look. If this is true, it is a show stopper.
> thanks
>
>
>
>
> ****************************************************************************
>
> ***
> This e-mail message is intended solely for the use of the addressee.
> The message may contain information that is privileged and
> confidential.
> Disclosure to anyone other than the intended recipient is prohibited.
> If you are not the intended recipient, please do not disseminate,
> distribute or copy this communication, by e-mail or otherwise. Instead,
> please notify us immediately by return e-mail(including the original
> message with your reply) and then delete and discard all copies of the
> message. We have taken precautions to minimize the risk of  transmitting
> software viruses but nevertheless advise you to carry out your own
> virus checks on any attachment to this message.  We accept
> no liability for any loss or damage caused by software viruses.
> ****************************************************************************
>
> ***
>
>
>
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>


-- 
Toli Kuznets
http://www.marketcetera.com: Open-Source Trading Platform
download.run.trade.

Re: [Quickfixj-users] repeating group problem

[Alvin W. <AW...@FF...>]

Steve,

The reason I do not want to use NewOrderSingle.NoPartyIDs is that my order
object can be either a NewOrderSingle or NewOrderMultileg. Not sure if I
can add a NewOrderSingle.NoPartyIDs  object to a NewOrderMultileg object?
Could you clarify? Just wonder why there is not an abstract class sitting
on the top like GeneralOrder which can enclose some common fields or
classes like NoPartyIDs?

BTW, could you tell me how I can get the latest build if you have some new
fixes?

thanks






                                                                           
             "Steve Bate"                                                  
             <steve@technoetic                                             
             .com>                                                      To 
             Sent by:                  <qui...@li.... 
             quickfixj-users-b         net>                                
             ou...@li...                                          cc 
             ceforge.net                                                   
                                                                   Subject 
                                       Re: [Quickfixj-users] repeating     
             11/03/2006 09:49          group problem                       
             PM                                                            
                                                                           
                                                                           
             Please respond to                                             
             quickfixj-users@l                                             
             ists.sourceforge.                                             
                    net                                                    
                                                                           
                                                                           



QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/
Alvin,

I recommend using the NewOrderSingle.NoPartyIDs rather than the
generic Group. The C++ code does create an ordering for the delimeter
field using the constructor you're using and QFJ does not. We can
change tnat behavior to be consistent with the C++ constructor but
this usage of the generic Group will be dangerous to use in both C++ and
QFJ. The C++ code happens to order the non-delimeter fields in key order,
which are tag numbers in this case. You are fortunate to have two
non-delimeter tags where the tag number ordering and the group field
ordering are the same. In general, you probably wouldn't be so lucky
since the ordering of the non-delimeter fields is undefined from an
API perspective when using this Group constructor.

If users want to create a generic Group rather than using the
message-specific groups we should probably create a constructor that
takes a group field tag number and a data dictionary and let the
constructor build the correct ordering criteria and determine the
delimeter field from the dictionary. It seems safer.

Oren, any comments?

Steve

-----Original Message-----
From: Alvin Wang [mailto:AW...@FF...]
Sent: Friday, November 03, 2006 2:22 PM
To: qui...@li...
Cc: qui...@li...;
qui...@li...
Subject: repeating group problem

        Group partyGroup = new Group(NoPartyIDs.FIELD, PartyID.FIELD);
        partyGroup.setField(new PartyID("TraderName"));
        partyGroup.setField(new
PartyIDSource(PartyIDSource.GENERALLY_ACCEPTED_MARKET_PARTICIPANT_IDENTIFIER

));
        partyGroup.setField(new PartyRole(11));
        order.addGroup(partyGroup);

We suspect that Quickfix/J does not create the right order, while QF's java
wrapper can with the same code above.

Quickfix/J:
453=1|447=C|448=TraderName|452=11     (448 should be the group delimiter)

QF's Java:
453=1|448=TraderName|447=C|452=11

Pls take a look. If this is true, it is a show stopper.
thanks




****************************************************************************

***
This e-mail message is intended solely for the use of the addressee.
The message may contain information that is privileged and
confidential.
Disclosure to anyone other than the intended recipient is prohibited.
If you are not the intended recipient, please do not disseminate,
distribute or copy this communication, by e-mail or otherwise. Instead,
please notify us immediately by return e-mail(including the original
message with your reply) and then delete and discard all copies of the
message. We have taken precautions to minimize the risk of  transmitting
software viruses but nevertheless advise you to carry out your own
virus checks on any attachment to this message.  We accept
no liability for any loss or damage caused by software viruses.
****************************************************************************

***






-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Quickfixj-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

[Quickfixj-users] My acceptor is still not responding properly

[Peter W. <pw...@bl...>]

Hi All,

=20

I still can't get a QFJ acceptor to respond correctly to an incoming
initiator.

So I'm going to start a new thread on this issue and lay out all the
information in the hope that someone can spot

the problem.

=20

The logs below show the acceptor starting up to listen for incoming =
orders:

20061101-15:26:03: Session FIX.4.3:SFCTRADE_TEST->APC_TEST schedule is
weekly, SUN 19:00:00 UTC - SAT 18:00:00 UTC

20061101-15:26:03: Session state is not current; resetting
FIX.4.3:SFCTRADE_TEST->APC_TEST

20061101-15:26:03: No responder, not sending message

20061101-15:26:03: Valid order types: [1]

20061101-15:26:03: Created session: FIX.4.3:SFCTRADE_TEST->APC_TEST

(this all looks correct given the entries in the config file)

=20

Then here comes the initiator's logon message:

8=3DFIX.4.3_9=3D83_35=3DA_34=3D17_49=3DAPC_TEST_50=3DFX_52=3D20061101-15:=
26:43.135_56=3DSFCT
RADE_TEST_98=3D0_108=3D30_10=3D207_

(34=3D17 so we are starting at a message sequence number of 17, =
shouldn't be a
problem?)

=20

And the acceptor accepting the message:

20061101-15:26:42: Accepting session FIX.4.3:SFCTRADE_TEST->APC_TEST =
from
/62.138.239.155:4847

20061101-15:26:42: Acceptor heartbeat set to 30 seconds

=20

And the next event . . .

20061101-15:26:42: Disconnecting

Sending a logout message . . .

8=3DFIX.4.3_9=3D64_35=3D5_34=3D1_49=3DSFCTRADE_TEST_52=3D20061101-15:26:4=
2.750_56=3DAPC_TE
ST_10=3D051_

(I note 34=3D1, is this the problem? I've also noticed the .seqnums file =
is
created, but empty with a zero length)

=20

The computer clocks are within 2 secs of each other.

If the problem is with synchronizing message numbers, doesn't the engine =
do
that?

Why does it disconnect?

=20

I'm adrift here. Anyone know how to break through?

=20

TIA

=20

Peter

London

=20

=20

=20

Re: [Quickfixj-users] repeating group problem

[Steve B. <st...@te...>]

Again, it's not a significant issue. I see validation and metadata
management as two separate responsibilities and representing two types
of functionality that can be used independently. For example, some
of the QF tools use the metadata but aren't concerned about
validation. It's possible someone would want to use the data dictionary
for message parsing but disable all or most validations by providing
a custom validator. For extended validators, the "something else" might
be custom validation logic such as a rule-based validator or some other
advanced validation mechanism. There might be a desire to store metadata
in a different format than XML, such as a database or a Spring Framework
configuration (for Java, of course). The tight coupling between the
validation and the data dictionary implementations make this a bit more
challenging.

Steve

> I'm not sure I necessarily agree about pulling validate out of the
> data dictionary.  I suppose if there is a use case where you want to
> validate against the data dictionary and something else.  If you are
> just validating against a data dictionary however, the validate
> method seems to be in an appropriate location to me.
> 
> --oren

Re: [Quickfixj-users] repeating group problem

[Oren M. <or...@qu...>]

Unfortunately the Ruby, Python, and C++ API's do not have a  
MessageFactory.  They were added to the Java and .NET APIs due to  
those languages very strict type checking.  We could probably add a  
MessageFactory to them for this purpose, even though the original use  
case of it isn't relevant to those languages.  A dynamic message  
factory could be pretty cool because we could probably drop the  
requirement of passing a message factory to the initiator/acceptor  
(making all the APIs more similar to each other).  Each session with  
a data dictionary could use a dynamic factory, while ones without  
would just use the default.  I'm not sure if this would create any  
sort of significant performance repercussions.

I'm not sure I necessarily agree about pulling validate out of the  
data dictionary.  I suppose if there is a use case where you want to  
validate against the data dictionary and something else.  If you are  
just validating against a data dictionary however, the validate  
method seems to be in an appropriate location to me.

--oren

On Nov 6, 2006, at 1:01 PM, st...@te... wrote:

>> Dynamically creating groups based on the DataDictionary is an
>> interesting idea.  What do you think of flipping it around a little
>> and turning the DataDictionary into a kind of factory.  I'm thinking:
>>
>> Group group = dataDictionary.createGroup( "X", NoPartyIDs.FIELD )
>>
>> Then you can even add createMessage( "X" ), and createField methods.
>> Could be useful for some use cases that require more dynamic
>> capabilities.
>
> Interesting idea. It would be nice to have a dynamic factory. What  
> about
> using (and extending) the quickfix.MessageFactory with an  
> implementation
> that uses a data dictionary for generating messages and parts of  
> messages
> like groups, components and fields?
>
> The only minor concern I have about adding it to the DataDictionary is
> that this seems to add a new responsibility to the dictionary. I'd  
> even
> like to see validation extracted to a validator class rather than  
> tightly
> coupled to the metadata management provided by the DataDictionary.
>
> Regards,
>
> Steve
>
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>

Re: [Quickfixj-users] repeating group problem

[Alvin W. <AW...@FF...>]

Steve,

Could you tell me how I can get the latest build? thanks,

Alvin




                                                                           
             steve@technoetic.                                             
             com                                                           
             Sent by:                                                   To 
             quickfixj-users-b         qui...@li....n 
             ou...@li...         et                                  
             ceforge.net                                                cc 
                                                                           
                                                                   Subject 
             11/06/2006 02:01          Re: [Quickfixj-users] repeating     
             PM                        group problem                       
                                                                           
                                                                           
             Please respond to                                             
             quickfixj-users@l                                             
             ists.sourceforge.                                             
                    net                                                    
                                                                           
                                                                           



QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/
> Yeah, I would recommend adopting the same practice as the C++ engine
> of placing the delimiter first no matter what.  For all practical
> purposes, this is all you really need.  The spec does specify that
> all fields must be in a certain order, but most implementations,
> QuickFIX included, do not care as long as the delimiter is in the
> right place.  Despite this, your recommendation of using the
> generated group is the best way to go.

I've made the change in the QFJ trunk.

> Dynamically creating groups based on the DataDictionary is an
> interesting idea.  What do you think of flipping it around a little
> and turning the DataDictionary into a kind of factory.  I'm thinking:
>
> Group group = dataDictionary.createGroup( "X", NoPartyIDs.FIELD )
>
> Then you can even add createMessage( "X" ), and createField methods.
> Could be useful for some use cases that require more dynamic
> capabilities.

Interesting idea. It would be nice to have a dynamic factory. What about
using (and extending) the quickfix.MessageFactory with an implementation
that uses a data dictionary for generating messages and parts of messages
like groups, components and fields?

The only minor concern I have about adding it to the DataDictionary is
that this seems to add a new responsibility to the dictionary. I'd even
like to see validation extracted to a validator class rather than tightly
coupled to the metadata management provided by the DataDictionary.

Regards,

Steve


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Quickfixj-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfixj-users




                                                                *******************************************************************************
This e-mail message is intended solely for the use of the addressee.
The message may contain information that is privileged and 
confidential.
Disclosure to anyone other than the intended recipient is prohibited.
If you are not the intended recipient, please do not disseminate,
distribute or copy this communication, by e-mail or otherwise. Instead,
please notify us immediately by return e-mail(including the original
message with your reply) and then delete and discard all copies of the
message. We have taken precautions to minimize the risk of  transmitting
software viruses but nevertheless advise you to carry out your own
virus checks on any attachment to this message.  We accept
no liability for any loss or damage caused by software viruses.
*******************************************************************************

Re: [Quickfixj-users] repeating group problem

[<st...@te...>]

> Yeah, I would recommend adopting the same practice as the C++ engine
> of placing the delimiter first no matter what.  For all practical
> purposes, this is all you really need.  The spec does specify that
> all fields must be in a certain order, but most implementations,
> QuickFIX included, do not care as long as the delimiter is in the
> right place.  Despite this, your recommendation of using the
> generated group is the best way to go.

I've made the change in the QFJ trunk.

> Dynamically creating groups based on the DataDictionary is an
> interesting idea.  What do you think of flipping it around a little
> and turning the DataDictionary into a kind of factory.  I'm thinking:
>
> Group group = dataDictionary.createGroup( "X", NoPartyIDs.FIELD )
>
> Then you can even add createMessage( "X" ), and createField methods.
> Could be useful for some use cases that require more dynamic
> capabilities.

Interesting idea. It would be nice to have a dynamic factory. What about
using (and extending) the quickfix.MessageFactory with an implementation
that uses a data dictionary for generating messages and parts of messages
like groups, components and fields?

The only minor concern I have about adding it to the DataDictionary is
that this seems to add a new responsibility to the dictionary. I'd even
like to see validation extracted to a validator class rather than tightly
coupled to the metadata management provided by the DataDictionary.

Regards,

Steve

Re: [Quickfixj-users] repeating group problem

[Oren M. <or...@qu...>]

Yeah, I would recommend adopting the same practice as the C++ engine  
of placing the delimiter first no matter what.  For all practical  
purposes, this is all you really need.  The spec does specify that  
all fields must be in a certain order, but most implementations,  
QuickFIX included, do not care as long as the delimiter is in the  
right place.  Despite this, your recommendation of using the  
generated group is the best way to go.

Dynamically creating groups based on the DataDictionary is an  
interesting idea.  What do you think of flipping it around a little  
and turning the DataDictionary into a kind of factory.  I'm thinking:

Group group = dataDictionary.createGroup( "X", NoPartyIDs.FIELD )

Then you can even add createMessage( "X" ), and createField methods.   
Could be useful for some use cases that require more dynamic  
capabilities.

--oren

On Nov 3, 2006, at 8:49 PM, Steve Bate wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
> Alvin,
>
> I recommend using the NewOrderSingle.NoPartyIDs rather than the
> generic Group. The C++ code does create an ordering for the delimeter
> field using the constructor you're using and QFJ does not. We can
> change tnat behavior to be consistent with the C++ constructor but
> this usage of the generic Group will be dangerous to use in both C+ 
> + and
> QFJ. The C++ code happens to order the non-delimeter fields in key  
> order,
> which are tag numbers in this case. You are fortunate to have two
> non-delimeter tags where the tag number ordering and the group field
> ordering are the same. In general, you probably wouldn't be so lucky
> since the ordering of the non-delimeter fields is undefined from an
> API perspective when using this Group constructor.
>
> If users want to create a generic Group rather than using the
> message-specific groups we should probably create a constructor that
> takes a group field tag number and a data dictionary and let the
> constructor build the correct ordering criteria and determine the
> delimeter field from the dictionary. It seems safer.
>
> Oren, any comments?
>
> Steve

Re: [Quickfixj-users] repeating group problem

[Steve B. <st...@te...>]

Alvin,

I recommend using the NewOrderSingle.NoPartyIDs rather than the
generic Group. The C++ code does create an ordering for the delimeter
field using the constructor you're using and QFJ does not. We can
change tnat behavior to be consistent with the C++ constructor but 
this usage of the generic Group will be dangerous to use in both C++ and
QFJ. The C++ code happens to order the non-delimeter fields in key order, 
which are tag numbers in this case. You are fortunate to have two
non-delimeter tags where the tag number ordering and the group field 
ordering are the same. In general, you probably wouldn't be so lucky
since the ordering of the non-delimeter fields is undefined from an
API perspective when using this Group constructor.

If users want to create a generic Group rather than using the
message-specific groups we should probably create a constructor that
takes a group field tag number and a data dictionary and let the
constructor build the correct ordering criteria and determine the
delimeter field from the dictionary. It seems safer.

Oren, any comments?

Steve

-----Original Message-----
From: Alvin Wang [mailto:AW...@FF...] 
Sent: Friday, November 03, 2006 2:22 PM
To: qui...@li...
Cc: qui...@li...;
qui...@li...
Subject: repeating group problem

        Group partyGroup = new Group(NoPartyIDs.FIELD, PartyID.FIELD);
        partyGroup.setField(new PartyID("TraderName"));
        partyGroup.setField(new
PartyIDSource(PartyIDSource.GENERALLY_ACCEPTED_MARKET_PARTICIPANT_IDENTIFIER
));
        partyGroup.setField(new PartyRole(11));
        order.addGroup(partyGroup);

We suspect that Quickfix/J does not create the right order, while QF's java
wrapper can with the same code above.

Quickfix/J:
453=1|447=C|448=TraderName|452=11     (448 should be the group delimiter)

QF's Java:
453=1|448=TraderName|447=C|452=11

Pls take a look. If this is true, it is a show stopper.
thanks



 
****************************************************************************
***
This e-mail message is intended solely for the use of the addressee.
The message may contain information that is privileged and 
confidential.
Disclosure to anyone other than the intended recipient is prohibited.
If you are not the intended recipient, please do not disseminate,
distribute or copy this communication, by e-mail or otherwise. Instead,
please notify us immediately by return e-mail(including the original
message with your reply) and then delete and discard all copies of the
message. We have taken precautions to minimize the risk of  transmitting
software viruses but nevertheless advise you to carry out your own
virus checks on any attachment to this message.  We accept
no liability for any loss or damage caused by software viruses.
****************************************************************************
***

[Quickfixj-users] repeating group problem

[Alvin W. <AW...@FF...>]

        Group partyGroup = new Group(NoPartyIDs.FIELD, PartyID.FIELD);
        partyGroup.setField(new PartyID("TraderName"));
        partyGroup.setField(new
PartyIDSource(PartyIDSource.GENERALLY_ACCEPTED_MARKET_PARTICIPANT_IDENTIFIER));
        partyGroup.setField(new PartyRole(11));
        order.addGroup(partyGroup);

We suspect that Quickfix/J does not create the right order, while QF's java
wrapper can with the same code above.

Quickfix/J:
453=1|447=C|448=TraderName|452=11     (448 should be the group delimiter)

QF's Java:
453=1|448=TraderName|447=C|452=11

Pls take a look. If this is true, it is a show stopper.
thanks



                                                                *******************************************************************************
This e-mail message is intended solely for the use of the addressee.
The message may contain information that is privileged and 
confidential.
Disclosure to anyone other than the intended recipient is prohibited.
If you are not the intended recipient, please do not disseminate,
distribute or copy this communication, by e-mail or otherwise. Instead,
please notify us immediately by return e-mail(including the original
message with your reply) and then delete and discard all copies of the
message. We have taken precautions to minimize the risk of  transmitting
software viruses but nevertheless advise you to carry out your own
virus checks on any attachment to this message.  We accept
no liability for any loss or damage caused by software viruses.
*******************************************************************************