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

[Quickfixj-users] Missing Logout Admin Message

[Daniel C. <da...@bl...>]

Hi,

I think this is an old issue, but still seems to be a problem with the
latest version of quickfixj 2.1.0.

After my initiator sends a Logon message, the acceptor immediately sends
back a Logout Message followed by closing the connection. Looking at the
tcpdump, it is clear why the connection is closed

    x.x.x.x.56988 > x.x.x.x.25265: Flags [P.], cksum 0x9863 (incorrect ->
0xe431), seq 1:104, ack 1, win 21, length 103
E.....@
.@..t..........b.(.7.>..+P....c..8=FIX.4.2.9=81.35=A.34=1161.49=XXX.52=20181130-15:08:36.259.56=***.98=0.108=10.554=***.10=026.
15:08:36.336321 IP (tos 0x60, ttl 48, id 0, offset 0, flags [DF], proto TCP
(6), length 188)
    x.x.x.x.x > x.x.x.x.56988: Flags [P.], cksum 0xdd5d (correct), seq
1:149, ack 104, win 4096, length 148
E`....@.0...........b...>..+(.8YP....]..*8=FIX.4.2.9=0124.35=5.34=552397.49=XXX.52=20181130-15:08:36.298.56=XXX.789=469881.58=MsgSeqNum
too low, expecting 469881 but received 1161.10=079*.

The problem is that *fromAdmin* is *never* called before *onLogout* because
of the connection reset following the logout message. I really need to
access this logout message for a couple of internal reasons.

Is there any workaround for this issue available?

Thanks
Daniel Cullender

Re: [Quickfixj-users] SessionSettings gets cleared out

[Christoph J. <chr...@ma...>]

Hi Alex,

great, thank you. I will leave some comments on the pull request. 
https://github.com/quickfix-j/quickfixj/pull/216

Cheers,
Chris.


On 21/11/2018 13:42, Alex Wibowo wrote:
> Hi Christoph,
>
> I have created a PR for this. Seems like changing 'sections' in SessionSettings fix the issue. I 
> have also created an end-to-end test on my project that I have configured to run overnight. So far 
> the result is looking positive with the change.
>
> Regards,
>
> Alex
>
> On Wed, Nov 21, 2018 at 11:00 PM Christoph John <chr...@ma... 
> <mailto:chr...@ma...>> wrote:
>
>     Hi Alex,
>
>     unfortunately I am out of ideas at the moment but there are two components which I cannot use
>     to reproduce the error. The first is Spring, the other one is Zing VM (according to your stack
>     traces).
>     Maybe you can also test to not inject the config by Spring but to construct and pass it
>     manually. I don't know which initialization guarantees Spring has nor how its internal thread
>     model works. To me this looks like a problem of visibility. So just for testing you could also
>     add "volatile" to all variables to see if the problem goes away. ;)
>
>     Sorry for not being more helpful but to further analyse the issue we need a reproducer e.g.
>     unit test.
>
>     Chris.
>
-- 
Christoph John
Software Engineering
T +49 241 557080-28
chr...@ma...

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald

Re: [Quickfixj-users] SessionSettings gets cleared out

[Alex W. <ale...@gm...>]

Hi Christoph,

I have created a PR for this. Seems like changing 'sections' in
SessionSettings fix the issue. I have also created an end-to-end test on my
project that I have configured to run overnight. So far the result is
looking positive with the change.

Regards,

Alex

On Wed, Nov 21, 2018 at 11:00 PM Christoph John <chr...@ma...>
wrote:

> Hi Alex,
>
> unfortunately I am out of ideas at the moment but there are two components
> which I cannot use to reproduce the error. The first is Spring, the other
> one is Zing VM (according to your stack traces).
> Maybe you can also test to not inject the config by Spring but to
> construct and pass it manually. I don't know which initialization
> guarantees Spring has nor how its internal thread model works. To me this
> looks like a problem of visibility. So just for testing you could also add
> "volatile" to all variables to see if the problem goes away. ;)
>
> Sorry for not being more helpful but to further analyse the issue we need
> a reproducer e.g. unit test.
>
> Chris.
>
>
> On 20/11/2018 19:44, Alex Wibowo wrote:
>
>
> I probably should also mention how the session settings look like.
> Roughly, it is like below (configured in Spring xml):
>
> <bean id="quickfixConfiguration"
> class="com.foobar.quickfix.QuickfixjConfiguration">
>     <property name="defaultSettings">
>         <util:map>
>             <!-- Custom Properties -->
>             <entry key="ResourceName" value="dapi"/>
>             <entry key="AsynchronousLogging" value="N"/>
>             <entry key="AsynchronousLoggerMaxPoolSize" value="1"/>
>             <entry key="AsynchronousLoggerQueueCapacity" value="100"/>
>             <entry key="AsynchronousLoggerThreadNamePrefix"
> value="QuickfixAsynchronousFileLogger-"/>
>             <!-- End of custom properties -->
>
>             <entry key="TimeZone" value="UTC"/>
>             <entry key="StartDay" value="Sunday"/>
>             <entry key="StartTime" value="7:00:00"/>
>             <entry key="EndDay" value="Friday"/>
>             <entry key="EndTime" value="17:00:00"/>
>             <entry key="NonStopSession" value="N"/>
>             <entry key="ConnectionType" value="acceptor"/>
>             <entry key="HeartBtInt" value="30"/>
>             <entry key="UseDataDictionary" value="Y"/>
>             <entry key="ThreadModel" value="ThreadPerSession"/>
>             <entry key="UseJmx" value="Y"/>
>             <entry key="FileStorePath"
> value="/home/wibowoa/var/lib/myApp"/>
>             <entry key="FileLogPath" value="logs/fixlog"/>
>             <entry key="FileIncludeTimeStampForMessages" value="Y"/>
>             <entry key="FileIncludeMilliseconds" value="Y"/>
>             <entry key="CheckLatency" value="Y"/>
>             <entry key="BeginString" value="FIX.4.2"/>
>             <entry key="AcceptorTemplate" value="Y"/>
>             <entry key="TargetCompID" value="*"/>
>         </util:map>
>     </property>
>     <property name="sessionSettings">
>         <util:map>
>             <entry key="FIX.4.2:FOOBAR_PRICING->*">
>                 <util:map>
>                     <entry key="PersistMessages" value="N"/>
>                     <entry key="SocketAcceptPort" value="7565"/>
>                     <entry key="DataDictionary"
> value="fix/FIX42-DAPI-MD-2.4.xml"/>
>                     <entry key="ResetOnLogon" value="Y"/>
>                     <entry key="MaxLatency" value="120"/>
>                 </util:map>
>             </entry>
>             <entry key="FIX.4.2:FOOBAR_TRADING->*">
>                 <util:map>
>                     <entry key="PersistMessages" value="Y"/>
>                     <entry key="SocketAcceptPort" value="7566"/>
>                     <entry key="DataDictionary"
> value="fix/FIX42-DAPI-TR-2.4.xml"/>
>                     <entry key="ResetOnLogon" value="N"/>
>                     <entry key="MaxLatency" value="1"/>
>                 </util:map>
>             </entry>
>         </util:map>
>     </property>
> </bean>
>
> then this gets loaded into SessionSettings:
>
> public final class QuickfixjConfiguration {
>     private Map<Object, Object> defaultSettings;
>     private Map<SessionID, Map<Object, Object>> sessionSettings;
>
>
>     public void setDefaultSettings(final Map<Object, Object>
> defaultSettings) {
>         this.defaultSettings = defaultSettings;
>     }
>
>     public Map<SessionID, Map<Object, Object>> getSessionSettings() {
>         return sessionSettings;
>     }
>
>     public void setSessionSettings(final Map<SessionID, Map<Object,
> Object>> sessionSettings) {
>         this.sessionSettings = sessionSettings;
>     }
>
>     public SessionSettings createSessionSettings() throws ConfigError {
>         final SessionSettings settings = new SessionSettings();
>         if(defaultSettings != null && !defaultSettings.isEmpty()) {
>             settings.set(new Dictionary(null, defaultSettings));
>         }
>         if(sessionSettings != null && !sessionSettings.isEmpty()) {
>             for (Map.Entry<SessionID, Map<Object, Object>> sessionSetting
> : sessionSettings.entrySet()) {
>                 settings.set(sessionSetting.getKey(), new
> Dictionary("session", sessionSetting.getValue()));
>             }
>         }
>         return settings;
>     }
>
> }
> ...
> QuickfixJConfiguration foobar =... (injected as spring)
> SessionSettings settings = foobar.createSessionSettings();
>
>   final MessageFactory messageFactory = new DefaultMessageFactory();
>         final LogFactory logFactory = ...
>         final MessageStoreFactory messageStoreFactory = new
> CustomFileStoreFactory(settings);
> final Acceptor acceptor =  new ThreadedSocketAcceptor(application,
> messageStoreFactory, settings, logFactory, messageFactory);
>
>   for (final SessionID sessionID :
> (Iterable<SessionID>)(settings::sectionIterator)) {
>                  final int acceptPort = (int) settings.getLong(sessionID,
> Acceptor.SETTING_SOCKET_ACCEPT_PORT);
>                  if (settings.getBool(sessionID,
> Acceptor.SETTING_ACCEPTOR_TEMPLATE)) {
>                                             final AcceptorSessionProvider
> dynamicAcceptorSessionProvider = new
> DynamicAcceptorSessionProvider(settings, sessionID, application,
> messageStoreFactory, logFactory, messageFactory);
>
> acceptor.setSessionProvider(new InetSocketAddress(acceptPort),
> dynamicAcceptorSessionProvider);
>                    }
> }
> ---------------------
>
> All of this was done during Spring context initialisation.
>
> Regards,
>
> Alex
>
>
> --
> Christoph John
> Software Engineering
> T +49 241 557...@ma...
>
> MACD GmbH
> Oppenhoffallee 103
> 52066 Aachen, Germanywww.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
>

-- 
Best regards,


Alex Wibowo

Re: [Quickfixj-users] SessionSettings gets cleared out

[Christoph J. <chr...@ma...>]

Hi Alex,

unfortunately I am out of ideas at the moment but there are two components which I cannot use to 
reproduce the error. The first is Spring, the other one is Zing VM (according to your stack traces).
Maybe you can also test to not inject the config by Spring but to construct and pass it manually. I 
don't know which initialization guarantees Spring has nor how its internal thread model works. To me 
this looks like a problem of visibility. So just for testing you could also add "volatile" to all 
variables to see if the problem goes away. ;)

Sorry for not being more helpful but to further analyse the issue we need a reproducer e.g. unit test.

Chris.


On 20/11/2018 19:44, Alex Wibowo wrote:
>
> I probably should also mention how the session settings look like.
> Roughly, it is like below (configured in Spring xml):
>
> <bean id="quickfixConfiguration" class="com.foobar.quickfix.QuickfixjConfiguration">
>     <property name="defaultSettings">
>         <util:map>
>             <!-- Custom Properties -->
>             <entry key="ResourceName" value="dapi"/>
>             <entry key="AsynchronousLogging" value="N"/>
>             <entry key="AsynchronousLoggerMaxPoolSize" value="1"/>
>             <entry key="AsynchronousLoggerQueueCapacity" value="100"/>
>             <entry key="AsynchronousLoggerThreadNamePrefix" value="QuickfixAsynchronousFileLogger-"/>
>             <!-- End of custom properties -->
>
>             <entry key="TimeZone" value="UTC"/>
>             <entry key="StartDay" value="Sunday"/>
>             <entry key="StartTime" value="7:00:00"/>
>             <entry key="EndDay" value="Friday"/>
>             <entry key="EndTime" value="17:00:00"/>
>             <entry key="NonStopSession" value="N"/>
>             <entry key="ConnectionType" value="acceptor"/>
>             <entry key="HeartBtInt" value="30"/>
>             <entry key="UseDataDictionary" value="Y"/>
>             <entry key="ThreadModel" value="ThreadPerSession"/>
>             <entry key="UseJmx" value="Y"/>
>             <entry key="FileStorePath" value="/home/wibowoa/var/lib/myApp"/>
>             <entry key="FileLogPath" value="logs/fixlog"/>
>             <entry key="FileIncludeTimeStampForMessages" value="Y"/>
>             <entry key="FileIncludeMilliseconds" value="Y"/>
>             <entry key="CheckLatency" value="Y"/>
>             <entry key="BeginString" value="FIX.4.2"/>
>             <entry key="AcceptorTemplate" value="Y"/>
>             <entry key="TargetCompID" value="*"/>
>         </util:map>
>     </property>
>     <property name="sessionSettings">
>         <util:map>
>             <entry key="FIX.4.2:FOOBAR_PRICING->*">
>                 <util:map>
>                     <entry key="PersistMessages" value="N"/>
>                     <entry key="SocketAcceptPort" value="7565"/>
>                     <entry key="DataDictionary" value="fix/FIX42-DAPI-MD-2.4.xml"/>
>                     <entry key="ResetOnLogon" value="Y"/>
>                     <entry key="MaxLatency" value="120"/>
>                 </util:map>
>             </entry>
>             <entry key="FIX.4.2:FOOBAR_TRADING->*">
>                 <util:map>
>                     <entry key="PersistMessages" value="Y"/>
>                     <entry key="SocketAcceptPort" value="7566"/>
>                     <entry key="DataDictionary" value="fix/FIX42-DAPI-TR-2.4.xml"/>
>                     <entry key="ResetOnLogon" value="N"/>
>                     <entry key="MaxLatency" value="1"/>
>                 </util:map>
>             </entry>
>         </util:map>
>     </property>
> </bean>
>
> then this gets loaded into SessionSettings:
>
> public final class QuickfixjConfiguration {
>     private Map<Object, Object> defaultSettings;
>     private Map<SessionID, Map<Object, Object>> sessionSettings;
>
>
>     public void setDefaultSettings(final Map<Object, Object> defaultSettings) {
>         this.defaultSettings = defaultSettings;
>     }
>
>     public Map<SessionID, Map<Object, Object>> getSessionSettings() {
>         return sessionSettings;
>     }
>
>     public void setSessionSettings(final Map<SessionID, Map<Object, Object>> sessionSettings) {
>         this.sessionSettings = sessionSettings;
>     }
>
>     public SessionSettings createSessionSettings() throws ConfigError {
>         final SessionSettings settings = new SessionSettings();
>         if(defaultSettings != null && !defaultSettings.isEmpty()) {
>             settings.set(new Dictionary(null, defaultSettings));
>         }
>         if(sessionSettings != null && !sessionSettings.isEmpty()) {
>             for (Map.Entry<SessionID, Map<Object, Object>> sessionSetting : 
> sessionSettings.entrySet()) {
>                 settings.set(sessionSetting.getKey(), new Dictionary("session", 
> sessionSetting.getValue()));
>             }
>         }
>         return settings;
>     }
>
> }
> ...
> QuickfixJConfiguration foobar =... (injected as spring)
> SessionSettings settings = foobar.createSessionSettings();
>
>   final MessageFactory messageFactory = new DefaultMessageFactory();
>         final LogFactory logFactory = ...
>         final MessageStoreFactory messageStoreFactory = new CustomFileStoreFactory(settings);
> final Acceptor acceptor =  new ThreadedSocketAcceptor(application, messageStoreFactory, settings, 
> logFactory, messageFactory);
>
>   for (final SessionID sessionID : (Iterable<SessionID>)(settings::sectionIterator)) {
>                  final int acceptPort = (int) settings.getLong(sessionID, 
> Acceptor.SETTING_SOCKET_ACCEPT_PORT);
>                  if (settings.getBool(sessionID, Acceptor.SETTING_ACCEPTOR_TEMPLATE)) {
>                                             final AcceptorSessionProvider 
> dynamicAcceptorSessionProvider = new DynamicAcceptorSessionProvider(settings, sessionID, 
> application, messageStoreFactory, logFactory, messageFactory);
> acceptor.setSessionProvider(new InetSocketAddress(acceptPort), dynamicAcceptorSessionProvider);
>                    }
> }
> ---------------------
>
> All of this was done during Spring context initialisation.
>
> Regards,
>
> Alex

-- 
Christoph John
Software Engineering
T +49 241 557080-28
chr...@ma...

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald

Re: [Quickfixj-users] SessionSettings gets cleared out

[Alex W. <ale...@gm...>]

Christoph,

I forgot to reply to one of your question about QFJ-963. I think this is a
different issue. Looking at the Stack trace, it is at different point, at
least...


Regards

Alex
-- 
Best regards,

Alex Wibowo

Re: [Quickfixj-users] SessionSettings gets cleared out

[Alex W. <ale...@gm...>]

I probably should also mention how the session settings look like.
Roughly, it is like below (configured in Spring xml):

<bean id="quickfixConfiguration"
class="com.foobar.quickfix.QuickfixjConfiguration">
    <property name="defaultSettings">
        <util:map>
            <!-- Custom Properties -->
            <entry key="ResourceName" value="dapi"/>
            <entry key="AsynchronousLogging" value="N"/>
            <entry key="AsynchronousLoggerMaxPoolSize" value="1"/>
            <entry key="AsynchronousLoggerQueueCapacity" value="100"/>
            <entry key="AsynchronousLoggerThreadNamePrefix"
value="QuickfixAsynchronousFileLogger-"/>
            <!-- End of custom properties -->

            <entry key="TimeZone" value="UTC"/>
            <entry key="StartDay" value="Sunday"/>
            <entry key="StartTime" value="7:00:00"/>
            <entry key="EndDay" value="Friday"/>
            <entry key="EndTime" value="17:00:00"/>
            <entry key="NonStopSession" value="N"/>
            <entry key="ConnectionType" value="acceptor"/>
            <entry key="HeartBtInt" value="30"/>
            <entry key="UseDataDictionary" value="Y"/>
            <entry key="ThreadModel" value="ThreadPerSession"/>
            <entry key="UseJmx" value="Y"/>
            <entry key="FileStorePath" value="/home/wibowoa/var/lib/myApp"/>
            <entry key="FileLogPath" value="logs/fixlog"/>
            <entry key="FileIncludeTimeStampForMessages" value="Y"/>
            <entry key="FileIncludeMilliseconds" value="Y"/>
            <entry key="CheckLatency" value="Y"/>
            <entry key="BeginString" value="FIX.4.2"/>
            <entry key="AcceptorTemplate" value="Y"/>
            <entry key="TargetCompID" value="*"/>
        </util:map>
    </property>
    <property name="sessionSettings">
        <util:map>
            <entry key="FIX.4.2:FOOBAR_PRICING->*">
                <util:map>
                    <entry key="PersistMessages" value="N"/>
                    <entry key="SocketAcceptPort" value="7565"/>
                    <entry key="DataDictionary"
value="fix/FIX42-DAPI-MD-2.4.xml"/>
                    <entry key="ResetOnLogon" value="Y"/>
                    <entry key="MaxLatency" value="120"/>
                </util:map>
            </entry>
            <entry key="FIX.4.2:FOOBAR_TRADING->*">
                <util:map>
                    <entry key="PersistMessages" value="Y"/>
                    <entry key="SocketAcceptPort" value="7566"/>
                    <entry key="DataDictionary"
value="fix/FIX42-DAPI-TR-2.4.xml"/>
                    <entry key="ResetOnLogon" value="N"/>
                    <entry key="MaxLatency" value="1"/>
                </util:map>
            </entry>
        </util:map>
    </property>
</bean>

then this gets loaded into SessionSettings:

public final class QuickfixjConfiguration {
    private Map<Object, Object> defaultSettings;
    private Map<SessionID, Map<Object, Object>> sessionSettings;


    public void setDefaultSettings(final Map<Object, Object>
defaultSettings) {
        this.defaultSettings = defaultSettings;
    }

    public Map<SessionID, Map<Object, Object>> getSessionSettings() {
        return sessionSettings;
    }

    public void setSessionSettings(final Map<SessionID, Map<Object,
Object>> sessionSettings) {
        this.sessionSettings = sessionSettings;
    }

    public SessionSettings createSessionSettings() throws ConfigError {
        final SessionSettings settings = new SessionSettings();
        if(defaultSettings != null && !defaultSettings.isEmpty()) {
            settings.set(new Dictionary(null, defaultSettings));
        }
        if(sessionSettings != null && !sessionSettings.isEmpty()) {
            for (Map.Entry<SessionID, Map<Object, Object>> sessionSetting :
sessionSettings.entrySet()) {
                settings.set(sessionSetting.getKey(), new
Dictionary("session", sessionSetting.getValue()));
            }
        }
        return settings;
    }

}
...
QuickfixJConfiguration foobar =... (injected as spring)
SessionSettings settings = foobar.createSessionSettings();

  final MessageFactory messageFactory = new DefaultMessageFactory();
        final LogFactory logFactory = ...
        final MessageStoreFactory messageStoreFactory = new
CustomFileStoreFactory(settings);
final Acceptor acceptor =  new ThreadedSocketAcceptor(application,
messageStoreFactory, settings, logFactory, messageFactory);

  for (final SessionID sessionID :
(Iterable<SessionID>)(settings::sectionIterator)) {
                 final int acceptPort = (int) settings.getLong(sessionID,
Acceptor.SETTING_SOCKET_ACCEPT_PORT);
                 if (settings.getBool(sessionID,
Acceptor.SETTING_ACCEPTOR_TEMPLATE)) {
                                            final AcceptorSessionProvider
dynamicAcceptorSessionProvider = new
DynamicAcceptorSessionProvider(settings, sessionID, application,
messageStoreFactory, logFactory, messageFactory);
                                            acceptor.setSessionProvider(new
InetSocketAddress(acceptPort), dynamicAcceptorSessionProvider);
                   }
}
---------------------

All of this was done during Spring context initialisation.

Regards,

Alex

Re: [Quickfixj-users] SessionSettings gets cleared out

[Colin D. <co...@ma...>]

Huh, well, I just looked at the source for DASP again, and I think it 
will work either way, though once for all sessions is more efficient. 
Prolly not your issue, then.


On 11/20/18 10:23 AM, Alex Wibowo wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hi Christoph & Colin,
>
> The SessionSettings is only constructed once, and it is on the same 
> thread as the ThreadedSocketAcceptor creation (they were created as 
> part of Spring context initialisation).
>
> Would changing the “sections” of the SessionSettings to ConcurrentMap 
> help ? I probably should mention that only a few of the 50 incoming 
> connections got the exception. As far as I know, the SessionSettings 
> given at the start is complete. Only then it is passed on to the 
> acceptor. Again, this only happened after we upgraded to 2.1.0 from 
> 1.5.3.
>
> Colin, I’m not sure about what you said about creating the 
> DynamicSession provider once only. If I looked at the sample code (on 
> the QuickfixJ github repo), it is doing the same thing.
>
> Thank you again, guys
>
>
> Regards
> Alex
>
> On Wed, 21 Nov 2018 at 2:57 am, Christoph John 
> <chr...@ma... <mailto:chr...@ma...>> wrote:
>
>     Hmm, in this case the problem seems to be in SessionSettings itself:
>
>        public Properties getSessionProperties(SessionID sessionID,
>     boolean includeDefaults)
>                 throws ConfigError {
>             final Properties p = sections.get(sessionID);
>
>             //////// here the ConfigError is thrown because there is
>     no section for the specified SessionID
>
>             if (p == null) {
>                 throw new ConfigError("Session not found");
>             }
>             if (includeDefaults) {
>                 final Properties mergedProperties = new Properties();
>     mergedProperties.putAll(sections.get(DEFAULT_SESSION_ID));
>                 mergedProperties.putAll(p);
>                 return mergedProperties;
>             } else {
>                 return p;
>             }
>         }
>
>     So the question is why the SessionSettings are incompletely
>     loaded. I take it that you pass the same SessionSettings object to
>     each acceptor? Is that SessionSettings object constructed/loaded
>     in the same thread as the Acceptor? One simple explanation could
>     be that the "sections" HashMap on the SessionSettings object is
>     non-volatile and could not be visible to all threads that access
>     it concurrently.
>
>     At least that is how it looks like from here.
>
>     Chris.
>
>
>
>     On 20/11/2018 06:09, Alex Wibowo wrote:
>>     Here is another variant of the failure. But I think the
>>     underlying cause is the same:
>>
>>     org.quickfixj.QFJException: quickfix.ConfigError: Session not found
>>
>>     at
>>     quickfix.mina.acceptor.DynamicAcceptorSessionProvider.getSession(DynamicAcceptorSessionProvider.java:153)
>>     ~[quickfixj-core-2.1.0.jar:2.1.0]
>>
>>     at
>>     quickfix.mina.acceptor.AcceptorIoHandler.findQFSession(AcceptorIoHandler.java:118)
>>     ~[quickfixj-core-2.1.0.jar:2.1.0]
>>
>>     at
>>     quickfix.mina.AbstractIoHandler.messageReceived(AbstractIoHandler.java:129)
>>     ~[quickfixj-core-2.1.0.jar:2.1.0]
>>
>>     at
>>     org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:997)
>>     ~[mina-core-2.0.19.jar:?]
>>
>>     at
>>     org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641)
>>     [mina-core-2.0.19.jar:?]
>>
>>     at
>>     org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48)
>>     [mina-core-2.0.19.jar:?]
>>
>>     at
>>     org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1114)
>>     [mina-core-2.0.19.jar:?]
>>
>>     at
>>     org.apache.mina.filter.codec.ProtocolCodecFilter$ProtocolDecoderOutputImpl.flush(ProtocolCodecFilter.java:437)
>>     [mina-core-2.0.19.jar:?]
>>
>>     at
>>     org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:256)
>>     [mina-core-2.0.19.jar:?]
>>
>>     at
>>     org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641)
>>     [mina-core-2.0.19.jar:?]
>>
>>     at
>>     org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48)
>>     [mina-core-2.0.19.jar:?]
>>
>>     at
>>     org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1114)
>>     [mina-core-2.0.19.jar:?]
>>
>>     at
>>     org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:121)
>>     [mina-core-2.0.19.jar:?]
>>
>>     at
>>     org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641)
>>     [mina-core-2.0.19.jar:?]
>>
>>     at
>>     org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:634)
>>     [mina-core-2.0.19.jar:?]
>>
>>     at
>>     org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:539)
>>     [mina-core-2.0.19.jar:?]
>>
>>     at
>>     org.apache.mina.core.polling.AbstractPollingIoProcessor.access$1200(AbstractPollingIoProcessor.java:68)
>>     [mina-core-2.0.19.jar:?]
>>
>>     at
>>     org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1242)
>>     [mina-core-2.0.19.jar:?]
>>
>>     at
>>     org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1231)
>>     [mina-core-2.0.19.jar:?]
>>
>>     at
>>     org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:683)
>>     [mina-core-2.0.19.jar:?]
>>
>>     at
>>     org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
>>     [mina-core-2.0.19.jar:?]
>>
>>     at
>>     java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>     [?:1.8.0_172]
>>
>>     at
>>     java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>     [?:1.8.0_172]
>>
>>     at java.lang.Thread.run(Thread.java:748) [?:1.8.0_172]
>>
>>     Caused by: quickfix.ConfigError: Session not found
>>
>>     at
>>     quickfix.SessionSettings.getSessionProperties(SessionSettings.java:165)
>>     ~[quickfixj-core-2.1.0.jar:2.1.0]
>>
>>     at
>>     quickfix.SessionSettings.getSessionProperties(SessionSettings.java:186)
>>     ~[quickfixj-core-2.1.0.jar:2.1.0]
>>
>>     at
>>     quickfix.mina.acceptor.DynamicAcceptorSessionProvider.getSession(DynamicAcceptorSessionProvider.java:140)
>>     ~[quickfixj-core-2.1.0.jar:2.1.0]
>>
>>     ... 24 more
>>
>>
>>     I'm really puzzled. As initially the configuration has non empty
>>     default properties & session properties. (our session properties
>>     use wildcards by the way, something like:
>>     FIX.4.2:OUR_SESSION_MARKET_DATA->*).
>>
>>
>>     I played around with the DynamicAcceptorSessionProvider,
>>     providing an override of the getSession() method:
>>
>>
>>
>>     @Override
>>
>>     public synchronized Session getSession(final SessionID
>>     clientConnection,
>>
>>                                        final SessionConnector
>>     sessionConnector) {
>>
>>     try {
>>
>>         return super.getSession(clientConnection, sessionConnector);
>>
>>     } catch (Exception e) {
>>
>>         LOGGER.info("Default session: {}",
>>     settings.getDefaultProperties());
>>
>>         throw e;
>>
>>     }
>>
>>                             }
>>
>>
>>     basically, catch the exception on failure, and inspect the
>>     default properties. The logged message shows empty default
>>     properties.
>>
>>     By the way, I've tried using SocketAcceptor, without any success
>>     either.
>>
>>
>>
>>
>>     Regards,
>>
>>
>>     Alex
>>
>>
>>     On Tue, Nov 20, 2018 at 11:32 AM Alex Wibowo
>>     <ale...@gm... <mailto:ale...@gm...>> wrote:
>>
>>
>>         Hi Christoph,
>>
>>         I should also mention that we are using
>>         ThreadedSocketAcceptor. So, it looks roughly like:
>>
>>         Acceptor acceptor = new ThreadedSocketAcceptor(application,
>>         messageStoreFactory, settings, logFactory, messageFactory);
>>
>>         for (final SessionID sessionID : (Iterable<SessionID>)
>>         settings::sectionIterator){
>>                         final int acceptPort = (int)
>>         settings.getLong(sessionID, Acceptor.SETTING_SOCKET_ACCEPT_PORT);
>>                         if (settings.getBool(sessionID,
>>         Acceptor.SETTING_ACCEPTOR_TEMPLATE)) {
>>
>>                                        final AcceptorSessionProvider
>>         dynamicAcceptorSessionProvider = new
>>         DynamicAcceptorSessionProvider(settings, sessionID,
>>         application, messageStoreFactory, logFactory, messageFactory);
>>          acceptor.setSessionProvider(new
>>         InetSocketAddress(acceptPort), dynamicAcceptorSessionProvider);
>>                     }
>>         }
>>
>>         The example and the test included in the project is using
>>         SocketAcceptor (instead of ThreadedSocketAcceptor).
>>
>>
>>         Regards,
>>
>>         Alex
>>
>>
>>
>>     -- 
>>     Best regards,
>>
>>
>>     Alex Wibowo
>
>     -- 
>     Christoph John
>     Software Engineering
>     T +49 241 557080-28
>     chr...@ma...  <mailto:chr...@ma...>
>
>     MACD GmbH
>     Oppenhoffallee 103 52066 Aachen, Germany  <https://maps.google.com/?q=Oppenhoffallee+103%0D%0A52066+Aachen,+Germany&entry=gmail&source=g>
>     www.macd.com  <http://www.macd.com>
>
>     Amtsgericht Aachen: HRB 8151
>     Ust.-Id: DE 813021663
>     Geschäftsführer: George Macdonald
>
> -- 
> Best regards,
>
> Alex Wibowo
>
>
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

-- 
Colin DuPlantis
Chief Architect, Marketcetera
Download, Run, Trade
888.868.4884
https://www.marketcetera.com

Re: [Quickfixj-users] SessionSettings gets cleared out

[Alex W. <ale...@gm...>]

Hi Christoph & Colin,

The SessionSettings is only constructed once, and it is on the same thread
as the ThreadedSocketAcceptor creation (they were created as part of Spring
context initialisation).

Would changing the “sections” of the SessionSettings to ConcurrentMap help
? I probably should mention that only a few of the 50 incoming connections
got the exception. As far as I know, the SessionSettings given at the start
is complete. Only then it is passed on to the acceptor. Again, this only
happened after we upgraded to 2.1.0 from 1.5.3.

Colin, I’m not sure about what you said about creating the DynamicSession
provider once only. If I looked at the sample code (on the QuickfixJ github
repo), it is doing the same thing.

Thank you again, guys


Regards
Alex

On Wed, 21 Nov 2018 at 2:57 am, Christoph John <chr...@ma...>
wrote:

> Hmm, in this case the problem seems to be in SessionSettings itself:
>
>    public Properties getSessionProperties(SessionID sessionID, boolean
> includeDefaults)
>             throws ConfigError {
>         final Properties p = sections.get(sessionID);
>
>         //////// here the ConfigError is thrown because there is no
> section for the specified SessionID
>
>         if (p == null) {
>             throw new ConfigError("Session not found");
>         }
>         if (includeDefaults) {
>             final Properties mergedProperties = new Properties();
>             mergedProperties.putAll(sections.get(DEFAULT_SESSION_ID));
>             mergedProperties.putAll(p);
>             return mergedProperties;
>         } else {
>             return p;
>         }
>     }
>
> So the question is why the SessionSettings are incompletely loaded. I take
> it that you pass the same SessionSettings object to each acceptor? Is that
> SessionSettings object constructed/loaded in the same thread as the
> Acceptor? One simple explanation could be that the "sections" HashMap on
> the SessionSettings object is non-volatile and could not be visible to all
> threads that access it concurrently.
>
> At least that is how it looks like from here.
>
> Chris.
>
>
>
> On 20/11/2018 06:09, Alex Wibowo wrote:
>
> Here is another variant of the failure. But I think the underlying cause
> is the same:
>
> org.quickfixj.QFJException: quickfix.ConfigError: Session not found
>
>           at
> quickfix.mina.acceptor.DynamicAcceptorSessionProvider.getSession(DynamicAcceptorSessionProvider.java:153)
> ~[quickfixj-core-2.1.0.jar:2.1.0]
>
>           at
> quickfix.mina.acceptor.AcceptorIoHandler.findQFSession(AcceptorIoHandler.java:118)
> ~[quickfixj-core-2.1.0.jar:2.1.0]
>
>           at
> quickfix.mina.AbstractIoHandler.messageReceived(AbstractIoHandler.java:129)
> ~[quickfixj-core-2.1.0.jar:2.1.0]
>
>           at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:997)
> ~[mina-core-2.0.19.jar:?]
>
>           at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641)
> [mina-core-2.0.19.jar:?]
>
>           at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48)
> [mina-core-2.0.19.jar:?]
>
>           at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1114)
> [mina-core-2.0.19.jar:?]
>
>           at
> org.apache.mina.filter.codec.ProtocolCodecFilter$ProtocolDecoderOutputImpl.flush(ProtocolCodecFilter.java:437)
> [mina-core-2.0.19.jar:?]
>
>           at
> org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:256)
> [mina-core-2.0.19.jar:?]
>
>           at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641)
> [mina-core-2.0.19.jar:?]
>
>           at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48)
> [mina-core-2.0.19.jar:?]
>
>           at
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1114)
> [mina-core-2.0.19.jar:?]
>
>           at
> org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:121)
> [mina-core-2.0.19.jar:?]
>
>           at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641)
> [mina-core-2.0.19.jar:?]
>
>           at
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:634)
> [mina-core-2.0.19.jar:?]
>
>           at
> org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:539)
> [mina-core-2.0.19.jar:?]
>
>           at
> org.apache.mina.core.polling.AbstractPollingIoProcessor.access$1200(AbstractPollingIoProcessor.java:68)
> [mina-core-2.0.19.jar:?]
>
>           at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1242)
> [mina-core-2.0.19.jar:?]
>
>           at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1231)
> [mina-core-2.0.19.jar:?]
>
>           at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:683)
> [mina-core-2.0.19.jar:?]
>
>           at
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
> [mina-core-2.0.19.jar:?]
>
>           at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [?:1.8.0_172]
>
>           at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [?:1.8.0_172]
>
>           at java.lang.Thread.run(Thread.java:748) [?:1.8.0_172]
>
> Caused by: quickfix.ConfigError: Session not found
>
>           at
> quickfix.SessionSettings.getSessionProperties(SessionSettings.java:165)
> ~[quickfixj-core-2.1.0.jar:2.1.0]
>
>           at
> quickfix.SessionSettings.getSessionProperties(SessionSettings.java:186)
> ~[quickfixj-core-2.1.0.jar:2.1.0]
>
>           at
> quickfix.mina.acceptor.DynamicAcceptorSessionProvider.getSession(DynamicAcceptorSessionProvider.java:140)
> ~[quickfixj-core-2.1.0.jar:2.1.0]
>
>           ... 24 more
>
>
> I'm really puzzled. As initially the configuration has non empty default
> properties & session properties. (our session properties use wildcards by
> the way, something like:  FIX.4.2:OUR_SESSION_MARKET_DATA->*).
>
>
> I played around with the DynamicAcceptorSessionProvider, providing an
> override of the getSession() method:
>
>
>
>                         @Override
>
>                         public synchronized Session getSession(final
> SessionID clientConnection,
>
>                                                                final
> SessionConnector sessionConnector) {
>
>                             try {
>
>                                 return super.getSession(clientConnection,
> sessionConnector);
>
>                             } catch (Exception e) {
>
>                                 LOGGER.info("Default session: {}",
> settings.getDefaultProperties());
>
>                                 throw e;
>
>                             }
>
>                         }
>
>
> basically, catch the exception on failure, and inspect the default
> properties. The logged message shows empty default properties.
>
> By the way, I've tried using SocketAcceptor, without any success either.
>
>
>
>
> Regards,
>
>
> Alex
>
> On Tue, Nov 20, 2018 at 11:32 AM Alex Wibowo <ale...@gm...> wrote:
>
>>
>> Hi Christoph,
>>
>> I should also mention that we are using ThreadedSocketAcceptor. So, it
>> looks roughly like:
>>
>> Acceptor acceptor = new ThreadedSocketAcceptor(application,
>> messageStoreFactory, settings, logFactory, messageFactory);
>>
>> for (final SessionID sessionID : (Iterable<SessionID>)
>> settings::sectionIterator){
>>                 final int acceptPort = (int) settings.getLong(sessionID,
>> Acceptor.SETTING_SOCKET_ACCEPT_PORT);
>>                 if (settings.getBool(sessionID,
>> Acceptor.SETTING_ACCEPTOR_TEMPLATE)) {
>>
>>                                final AcceptorSessionProvider
>> dynamicAcceptorSessionProvider = new
>> DynamicAcceptorSessionProvider(settings, sessionID, application,
>> messageStoreFactory, logFactory, messageFactory);
>>                                acceptor.setSessionProvider(new
>> InetSocketAddress(acceptPort), dynamicAcceptorSessionProvider);
>>             }
>> }
>>
>> The example and the test included in the project is using SocketAcceptor
>> (instead of ThreadedSocketAcceptor).
>>
>>
>> Regards,
>>
>> Alex
>>
>
>
> --
> Best regards,
>
>
> Alex Wibowo
>
>
> --
> Christoph John
> Software Engineering
> T +49 241 557...@ma...
>
> MACD GmbHOppenhoffallee 103
> 52066 Aachen, Germany <https://maps.google.com/?q=Oppenhoffallee+103%0D%0A52066+Aachen,+Germany&entry=gmail&source=g>www.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
> --
Best regards,

Alex Wibowo

Re: [Quickfixj-users] SessionSettings gets cleared out

[Colin D. <co...@ma...>]

I'm not sure what the whole history of this conversation is, but, 
something jumped out at me so I thought I'd just throw this out there.

In the code below, you create a DynamicAcceptorSessionProvider for 
*each* session. You should create just one for all sessions, right? Not 
sure if that will make a difference.

On 11/19/18 4:32 PM, Alex Wibowo wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
> 
> 
> 
> 
> Hi Christoph,
> 
> I should also mention that we are using ThreadedSocketAcceptor. So, it 
> looks roughly like:
> 
> Acceptor acceptor = new ThreadedSocketAcceptor(application, 
> messageStoreFactory, settings, logFactory, messageFactory);
> 
> for (final SessionID sessionID : (Iterable<SessionID>) 
> settings::sectionIterator){
>                  final int acceptPort = (int) 
> settings.getLong(sessionID, Acceptor.SETTING_SOCKET_ACCEPT_PORT);
>                  if (settings.getBool(sessionID, 
> Acceptor.SETTING_ACCEPTOR_TEMPLATE)) {
> 
>                                 final AcceptorSessionProvider 
> dynamicAcceptorSessionProvider = new 
> DynamicAcceptorSessionProvider(settings, sessionID, application, 
> messageStoreFactory, logFactory, messageFactory);
>                                 acceptor.setSessionProvider(new 
> InetSocketAddress(acceptPort), dynamicAcceptorSessionProvider);
>              }
> }
> 
> The example and the test included in the project is using SocketAcceptor 
> (instead of ThreadedSocketAcceptor).
> 
> 
> Regards,
> 
> Alex
> 
> 
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
> 

Re: [Quickfixj-users] SessionSettings gets cleared out

[Christoph J. <chr...@ma...>]

Hi Alex,

I meant that there was a bug in the old code that caused old sessions to be never cleaned up. But as 
you describe it, the case for you seems to be a different one.
Thanks for the additional information (ThreadedSocketAcceptor and 50 connections log in at the same 
time). That gives me another hint on where to look. I will report back as soon as I have an idea. 
But sounds to me like something is not initialized correctly when several threads access it.

I guess this has some overlaps with https://www.quickfixj.org/jira/browse/QFJ-963 .

Cheers,
Chris.



On 19/11/2018 20:00, Alex Wibowo wrote:
> Hi Christoph,
>
>
> Thank you again for your reply. I don’t quite understand what you meant by “old” dynamic session. 
> Did you mean it was actually a bug in 1.5.3, and behave properly in 2.1.0 ? For my case, the error 
> occurred during first time setup - I.e none of the session has not logged in before, and then 50 
> connections try to login at the same time..
> As far as I can tell, there is no call to the “removeSetting” on SessionSettings. So I am a bit 
> puzzled as to what could cause the settings to get cleared.
>
> Regards
>
> Alex
>
> On Tue, 20 Nov 2018 at 2:19 am, Christoph John <chr...@ma... 
> <mailto:chr...@ma...>> wrote:
>
>     Hi,
>
>     I heard recently that "old" dynamic sessions were not properly removed before QFJ 2.1.0. So
>     maybe this is a side effect of this. But just a wild guess though.
>     Anyway, please open a JIRA issue for this. Of course it would be the best if we could
>     reproduce it. :)
>
>     I briefly tested if this is a general problem but it does not seem likely. E.g. when I comment
>     line
>     https://github.com/quickfix-j/quickfixj/blob/fcee00fb1709bc3f1c62b9a893c0e38d873fd312/quickfixj-core/src/test/java/quickfix/mina/acceptor/DynamicAcceptorSessionProviderTest.java#L195
>     then the test fails with the error message "Missing ConnectionType". However, when I add
>
>     ownSettings.setString("ConnectionType", "acceptor");
>
>     , i.e. adding the ConnectionType to the DEFAULT section, the test passes.
>
>     Cheers,
>     Chris.
>

-- 
Christoph John
Software Engineering
T +49 241 557080-28
chr...@ma...

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald

Re: [Quickfixj-users] SessionSettings gets cleared out

[Alex W. <ale...@gm...>]

Hi Christoph,

I should also mention that we are using ThreadedSocketAcceptor. So, it
looks roughly like:

Acceptor acceptor = new ThreadedSocketAcceptor(application,
messageStoreFactory, settings, logFactory, messageFactory);

for (final SessionID sessionID : (Iterable<SessionID>)
settings::sectionIterator){
                final int acceptPort = (int) settings.getLong(sessionID,
Acceptor.SETTING_SOCKET_ACCEPT_PORT);
                if (settings.getBool(sessionID,
Acceptor.SETTING_ACCEPTOR_TEMPLATE)) {

                               final AcceptorSessionProvider
dynamicAcceptorSessionProvider = new
DynamicAcceptorSessionProvider(settings, sessionID, application,
messageStoreFactory, logFactory, messageFactory);
                               acceptor.setSessionProvider(new
InetSocketAddress(acceptPort), dynamicAcceptorSessionProvider);
            }
}

The example and the test included in the project is using SocketAcceptor
(instead of ThreadedSocketAcceptor).


Regards,

Alex

Re: [Quickfixj-users] Any way to clean up threads?

[Christoph J. <chr...@ma...>]

I am not sure if it works but you could try to replace the MINA JAR that is bundled with QFJ 1.6.3 and replace it with the current MINA 2.0.19. That *might* fix part of the problem. 

Cheers,
Chris.

Am 19. November 2018 19:40:47 MEZ schrieb Sean LeBlanc <sea...@ic...>:
>Ah, thanks, Chris, that's good to know. Unfortunately, we probably
>won't 
>be upgrading any time in the near-near future. :(
>
>
>But when we do, I will make a note to re-try this for our 
>automation/testing scenarios.
>
>
>Cheers!
>
>
>On 11/19/18 10:56 AM, Christoph John wrote:
>> Hi
>> I am pretty sure that this has been corrected in later versions.
>Could 
>> you retest with 2.1.0? IIRC there was also a bug in MINA.
>> Cheers,
>> Chris.
>>
>> Am 19. November 2018 17:38:56 MEZ schrieb Sean LeBlanc 
>> <sea...@ic...>:
>>
>>     Hello,
>>
>>
>>     we are using QuickFIX/J 1.6.3 and for testing, we sometimes stop
>>     initiators/acceptors and start them after changing their settings
>>     for test scenarios. However, it seems that after doing a stop on
>>     these objects still leaves some threads (e.g.,
>>     NIOSocketAcceptor-14,  QFJ Message Processor) around, and if this
>>     start/stop cycle is called enough times, the JVM eventually will
>>     hit an OS restriction on number of threads. If I were to bump
>that
>>     up, I would think the next problem would be memory, as that also
>>     gets quite large.
>>
>>     I've tried various scenarios to try to make these get cleaned up,
>>     but nothing I've done seems to work. What I've tried is: adding
>>     the "true" in the call to stop, trying to set initiator to null
>>
>>     To see what I'm talking about, attach something like Java
>VisualVM
>>     to your JVM, then do something like:
>>
>>
>>     initiator = new SocketInitiator(this, storeFactory,
>>     sessionSettings, logFactory, messageFactory)
>>
>>     initiator.start()
>>
>>     initiator.stop(true)
>>
>>     initiator.start()
>>
>>     ...
>>
>>     etc.
>>
>>
>>     ...and watch the thread count. Invoking GC directly doesn't seem
>>     to reap any of the threads, either. Acceptors seem to have
>similar
>>     behavior.
>>
>>
>>     Is there anything I could try to clear these?
>>
>>
>>     -- 
>>     *Sean LeBlanc*
>>     *Software Architect/Senior Software Engineer*
>>     *Institutional Cash Distributors Technology, LLC*
>>     Direct 720.453.1288
>>     Fax 720.453.1335
>>     sea...@ic... <mailto:sea...@ic...> |
>>     www.icdportal.com <http://www.icdportal.com/>
>>
>-- 
>*Sean LeBlanc*
>*Software Architect/Senior Software Engineer*
>*Institutional Cash Distributors Technology, LLC*
>Direct 720.453.1288
>Fax 720.453.1335
>sea...@ic... <mailto:sea...@ic...> | 
>www.icdportal.com <http://www.icdportal.com/>

Re: [Quickfixj-users] Any way to clean up threads?

[Sean L. <sea...@ic...>]

Ah, thanks, Chris, that's good to know. Unfortunately, we probably won't 
be upgrading any time in the near-near future. :(


But when we do, I will make a note to re-try this for our 
automation/testing scenarios.


Cheers!


On 11/19/18 10:56 AM, Christoph John wrote:
> Hi
> I am pretty sure that this has been corrected in later versions. Could 
> you retest with 2.1.0? IIRC there was also a bug in MINA.
> Cheers,
> Chris.
>
> Am 19. November 2018 17:38:56 MEZ schrieb Sean LeBlanc 
> <sea...@ic...>:
>
>     Hello,
>
>
>     we are using QuickFIX/J 1.6.3 and for testing, we sometimes stop
>     initiators/acceptors and start them after changing their settings
>     for test scenarios. However, it seems that after doing a stop on
>     these objects still leaves some threads (e.g.,
>     NIOSocketAcceptor-14,  QFJ Message Processor) around, and if this
>     start/stop cycle is called enough times, the JVM eventually will
>     hit an OS restriction on number of threads. If I were to bump that
>     up, I would think the next problem would be memory, as that also
>     gets quite large.
>
>     I've tried various scenarios to try to make these get cleaned up,
>     but nothing I've done seems to work. What I've tried is: adding
>     the "true" in the call to stop, trying to set initiator to null
>
>     To see what I'm talking about, attach something like Java VisualVM
>     to your JVM, then do something like:
>
>
>     initiator = new SocketInitiator(this, storeFactory,
>     sessionSettings, logFactory, messageFactory)
>
>     initiator.start()
>
>     initiator.stop(true)
>
>     initiator.start()
>
>     ...
>
>     etc.
>
>
>     ...and watch the thread count. Invoking GC directly doesn't seem
>     to reap any of the threads, either. Acceptors seem to have similar
>     behavior.
>
>
>     Is there anything I could try to clear these?
>
>
>     -- 
>     *Sean LeBlanc*
>     *Software Architect/Senior Software Engineer*
>     *Institutional Cash Distributors Technology, LLC*
>     Direct 720.453.1288
>     Fax 720.453.1335
>     sea...@ic... <mailto:sea...@ic...> |
>     www.icdportal.com <http://www.icdportal.com/>
>
-- 
*Sean LeBlanc*
*Software Architect/Senior Software Engineer*
*Institutional Cash Distributors Technology, LLC*
Direct 720.453.1288
Fax 720.453.1335
sea...@ic... <mailto:sea...@ic...> | 
www.icdportal.com <http://www.icdportal.com/>

Re: [Quickfixj-users] Any way to clean up threads?

[Christoph J. <chr...@ma...>]

Hi
I am pretty sure that this has been corrected in later versions. Could you retest with 2.1.0? IIRC there was also a bug in MINA. 
Cheers,
Chris. 

Am 19. November 2018 17:38:56 MEZ schrieb Sean LeBlanc <sea...@ic...>:
>QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>QuickFIX/J Support: http://www.quickfixj.org/support/

[Quickfixj-users] Any way to clean up threads?

[Sean L. <sea...@ic...>]

Hello,


we are using QuickFIX/J 1.6.3 and for testing, we sometimes stop 
initiators/acceptors and start them after changing their settings for 
test scenarios. However, it seems that after doing a stop on these 
objects still leaves some threads (e.g., NIOSocketAcceptor-14,  QFJ 
Message Processor) around, and if this start/stop cycle is called enough 
times, the JVM eventually will hit an OS restriction on number of 
threads. If I were to bump that up, I would think the next problem would 
be memory, as that also gets quite large.

I've tried various scenarios to try to make these get cleaned up, but 
nothing I've done seems to work. What I've tried is: adding the "true" 
in the call to stop, trying to set initiator to null

To see what I'm talking about, attach something like Java VisualVM to 
your JVM, then do something like:


initiator = new SocketInitiator(this, storeFactory, sessionSettings, 
logFactory, messageFactory)

initiator.start()

initiator.stop(true)

initiator.start()

...

etc.


...and watch the thread count. Invoking GC directly doesn't seem to reap 
any of the threads, either. Acceptors seem to have similar behavior.


Is there anything I could try to clear these?


-- 
*Sean LeBlanc*
*Software Architect/Senior Software Engineer*
*Institutional Cash Distributors Technology, LLC*
Direct 720.453.1288
Fax 720.453.1335
sea...@ic... <mailto:sea...@ic...> | 
www.icdportal.com <http://www.icdportal.com/>

Re: [Quickfixj-users] Initiator failover due to acceptor compID already in use

[Christoph J. <chr...@ma...>]

This is exactly like we have implemented it some time ago. But we never came around using it.


On 19/11/2018 17:18, Colin DuPlantis wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> No, I think you would be better off with a hot-warm configuration than a hot-hot one.
>
> We manage this by having one running process with an active FIX initiator and one running process 
> with the same settings but the initiator hasn't been started. If the first process goes down, the 
> second one automatically starts the FIX initiator. The first process actively suppresses the start 
> in the second, so, if the first process goes away, the second process will automatically start the 
> FIX sessions.
>
> On 11/19/18 8:05 AM, Tsz Shun Chow wrote:
>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>> QuickFIX/J Support:http://www.quickfixj.org/support/
>>
>>
>>
>> Yes. It’s basically our system tried to use a live-live (a pair of) FIX connections with the same 
>> targetCompID.
>>
>> Let’s say I run two instances (processes) of the app for redundancy. And they both have two 
>> addresses to initiate connections. So the remote peer has the connection with one of them. The 
>> another one is now stuck on trying the first because of the git commit I mentioned.
>>
>> Is it architecturally desirable using the same compID this way? We used the same to avoid two of 
>> our apps connecting to the same remote acceptor.
>>
>> On Mon, 19 Nov 2018 at 15:31, Christoph John <chr...@ma... 
>> <mailto:chr...@ma...>> wrote:
>>
>>     Hi,
>>
>>     sorry, I do not understand what you mean. When you say:
>>
>>>     when acceptor compID already in use by another initiator.
>>
>>     do you mean that the remote peer already has an established connection with another
>>     counterparty (instead of you)?
>>
>>     Chris.
>>
>>
>>
>>     On 19/11/2018 12:20, Tsz Shun Chow wrote:
>>>     QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>>     QuickFIX/J Support:http://www.quickfixj.org/support/
>>>
>>>
>>>
>>>     Hi all,
>>>
>>>     We have recently found a problem that Initiator failover was stuck with the first address
>>>     when acceptor compID already in use by another initiator.
>>>
>>>     It seem to be related to this, though I think the change only exposed the bug, not created it.
>>>
>>>     https://github.com/quickfix-j/quickfixj/commit/622b858d4a6d972b0d2006b5029f2be354d1dcdc
>>>
>>>     In the case of targetCompID in use, the session was connected and active, so the address
>>>     index set to one, even it was dropped afterwards. Then the initiator will try and fail
>>>     forever until the session of the targetCompID is available again.
>>>
>>>     How could the initiator detect the targetCompID in use and therefore could try next address
>>>     in the list?
>>>
>>>     Cheers
>>>     Jason
>>>

-- 
Christoph John
Software Engineering
T +49 241 557080-28
chr...@ma...

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald

Re: [Quickfixj-users] Initiator failover due to acceptor compID already in use

[Colin D. <co...@ma...>]

No, I think you would be better off with a hot-warm configuration than a 
hot-hot one.

We manage this by having one running process with an active FIX 
initiator and one running process with the same settings but the 
initiator hasn't been started. If the first process goes down, the 
second one automatically starts the FIX initiator. The first process 
actively suppresses the start in the second, so, if the first process 
goes away, the second process will automatically start the FIX sessions.

On 11/19/18 8:05 AM, Tsz Shun Chow wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Yes. It’s basically our system tried to use a live-live (a pair of) 
> FIX connections with the same targetCompID.
>
> Let’s say I run two instances (processes) of the app for redundancy. 
> And they both have two addresses to initiate connections. So the 
> remote peer has the connection with one of them. The another one is 
> now stuck on trying the first because of the git commit I mentioned.
>
> Is it architecturally desirable using the same compID this way? We 
> used the same to avoid two of our apps connecting to the same remote 
> acceptor.
>
> On Mon, 19 Nov 2018 at 15:31, Christoph John <chr...@ma... 
> <mailto:chr...@ma...>> wrote:
>
>     Hi,
>
>     sorry, I do not understand what you mean. When you say:
>
>>     when acceptor compID already in use by another initiator.
>
>     do you mean that the remote peer already has an established
>     connection with another counterparty (instead of you)?
>
>     Chris.
>
>
>
>     On 19/11/2018 12:20, Tsz Shun Chow wrote:
>>     QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>     QuickFIX/J Support:http://www.quickfixj.org/support/
>>
>>
>>
>>     Hi all,
>>
>>     We have recently found a problem that Initiator failover was
>>     stuck with the first address when acceptor compID already in use
>>     by another initiator.
>>
>>     It seem to be related to this, though I think the change only
>>     exposed the bug, not created it.
>>
>>     https://github.com/quickfix-j/quickfixj/commit/622b858d4a6d972b0d2006b5029f2be354d1dcdc
>>
>>     In the case of targetCompID in use, the session was connected and
>>     active, so the address index set to one, even it was dropped
>>     afterwards. Then the initiator will try and fail forever until
>>     the session of the targetCompID is available again.
>>
>>     How could the initiator detect the targetCompID in use and
>>     therefore could try next address in the list?
>>
>>     Cheers
>>     Jason
>>
>>
>>     _______________________________________________
>>     Quickfixj-users mailing list
>>     Qui...@li...  <mailto:Qui...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>     -- 
>     Christoph John
>     Software Engineering
>     T +49 241 557080-28
>     chr...@ma...  <mailto:chr...@ma...>
>
>     MACD GmbH
>     Oppenhoffallee 103 52066 Aachen, Germany  <https://maps.google.com/?q=Oppenhoffallee+103%0D%0A52066+Aachen,+Germany&entry=gmail&source=g>
>     www.macd.com  <http://www.macd.com>
>
>     Amtsgericht Aachen: HRB 8151
>     Ust.-Id: DE 813021663
>     Geschäftsführer: George Macdonald
>
>
>
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

-- 
Colin DuPlantis
Chief Architect, Marketcetera
Download, Run, Trade
888.868.4884
https://www.marketcetera.com

Re: [Quickfixj-users] Initiator failover due to acceptor compID already in use

[Tsz S. C. <jas...@gm...>]

Yes. It’s basically our system tried to use a live-live (a pair of) FIX
connections with the same targetCompID.

Let’s say I run two instances (processes) of the app for redundancy. And
they both have two addresses to initiate connections. So the remote peer
has the connection with one of them. The another one is now stuck on trying
the first because of the git commit I mentioned.

Is it architecturally desirable using the same compID this way? We used the
same to avoid two of our apps connecting to the same remote acceptor.

On Mon, 19 Nov 2018 at 15:31, Christoph John <chr...@ma...>
wrote:

> Hi,
>
> sorry, I do not understand what you mean. When you say:
>
> when acceptor compID already in use by another initiator.
>
>
> do you mean that the remote peer already has an established connection
> with another counterparty (instead of you)?
>
> Chris.
>
>
>
> On 19/11/2018 12:20, Tsz Shun Chow wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi all,
>
> We have recently found a problem that Initiator failover was stuck with
> the first address when acceptor compID already in use by another initiator.
>
> It seem to be related to this, though I think the change only exposed the
> bug, not created it.
>
>
> https://github.com/quickfix-j/quickfixj/commit/622b858d4a6d972b0d2006b5029f2be354d1dcdc
>
> In the case of targetCompID in use, the session was connected and active,
> so the address index set to one, even it was dropped afterwards. Then the
> initiator will try and fail forever until the session of the targetCompID
> is available again.
>
> How could the initiator detect the targetCompID in use and therefore could
> try next address in the list?
>
> Cheers
> Jason
>
>
> _______________________________________________
> Quickfixj-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>
> --
> Christoph John
> Software Engineering
> T +49 241 557...@ma...
>
> MACD GmbHOppenhoffallee 103
> 52066 Aachen, Germany <https://maps.google.com/?q=Oppenhoffallee+103%0D%0A52066+Aachen,+Germany&entry=gmail&source=g>www.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
>

Re: [Quickfixj-users] Initiator failover due to acceptor compID already in use

[Christoph J. <chr...@ma...>]

Hi,

sorry, I do not understand what you mean. When you say:

> when acceptor compID already in use by another initiator.

do you mean that the remote peer already has an established connection with another counterparty 
(instead of you)?

Chris.



On 19/11/2018 12:20, Tsz Shun Chow wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hi all,
>
> We have recently found a problem that Initiator failover was stuck with the first address when 
> acceptor compID already in use by another initiator.
>
> It seem to be related to this, though I think the change only exposed the bug, not created it.
>
> https://github.com/quickfix-j/quickfixj/commit/622b858d4a6d972b0d2006b5029f2be354d1dcdc
>
> In the case of targetCompID in use, the session was connected and active, so the address index set 
> to one, even it was dropped afterwards. Then the initiator will try and fail forever until the 
> session of the targetCompID is available again.
>
> How could the initiator detect the targetCompID in use and therefore could try next address in the 
> list?
>
> Cheers
> Jason
>
>
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

-- 
Christoph John
Software Engineering
T +49 241 557080-28
chr...@ma...

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald

Re: [Quickfixj-users] SessionSettings gets cleared out

[Christoph J. <chr...@ma...>]

Hi,

I heard recently that "old" dynamic sessions were not properly removed before QFJ 2.1.0. So maybe 
this is a side effect of this. But just a wild guess though.
Anyway, please open a JIRA issue for this. Of course it would be the best if we could reproduce it. :)

I briefly tested if this is a general problem but it does not seem likely. E.g. when I comment line 
https://github.com/quickfix-j/quickfixj/blob/fcee00fb1709bc3f1c62b9a893c0e38d873fd312/quickfixj-core/src/test/java/quickfix/mina/acceptor/DynamicAcceptorSessionProviderTest.java#L195 
then the test fails with the error message "Missing ConnectionType". However, when I add

ownSettings.setString("ConnectionType", "acceptor");

, i.e. adding the ConnectionType to the DEFAULT section, the test passes.

Cheers,
Chris.



On 19/11/2018 13:12, Alex Wibowo wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hi,
>
> We have been using DynamicAcceptorSessionProvider in our project for quite sometime now.
> After a recent upgrade to Quickfix 2.1.0 (from 1.5.3), we saw some errors that I believe is caused 
> by Quickfix being unable to find the session settings.
> The stack trace looks like below:
> -----
>
> 2018-11-19 00:01:13,236|| ERROR |||| org.quickfixj.QFJException: quickfix.ConfigError: Missing 
> ConnectionType | NioProcessor-23 | q.m.a.AcceptorIoHandler
>
> org.quickfixj.QFJException: quickfix.ConfigError: Missing ConnectionType
>
> at 
> quickfix.mina.acceptor.DynamicAcceptorSessionProvider.getSession(DynamicAcceptorSessionProvider.java:153) 
> ~[quickfixj-core-2.1.0.jar:2.1.0]
>
> at quickfix.mina.acceptor.AcceptorIoHandler.findQFSession(AcceptorIoHandler.java:118) 
> ~[quickfixj-core-2.1.0.jar:2.1.0]
>
> at quickfix.mina.AbstractIoHandler.messageReceived(AbstractIoHandler.java:129) 
> ~[quickfixj-core-2.1.0.jar:2.1.0]
>
>        at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:997) 
> ~[mina-core-2.0.19.jar:?]
>
> at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641) 
> [mina-core-2.0.19.jar:?]
>
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48) 
> [mina-core-2.0.19.jar:?]
>
> at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1114) 
> [mina-core-2.0.19.jar:?]
>
> at 
> org.apache.mina.filter.codec.ProtocolCodecFilter$ProtocolDecoderOutputImpl.flush(ProtocolCodecFilter.java:437) 
> [mina-core-2.0.19.jar:?]
>
> at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:256) 
> [mina-core-2.0.19.jar:?]
>
> at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641) 
> [mina-core-2.0.19.jar:?]
>
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48) 
> [mina-core-2.0.19.jar:?]
>
> at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1114) 
> [mina-core-2.0.19.jar:?]
>
> at org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:121) 
> [mina-core-2.0.19.jar:?]
>
> at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641) 
> [mina-core-2.0.19.jar:?]
>
> at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:634) 
> [mina-core-2.0.19.jar:?]
>
> at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:539) 
> [mina-core-2.0.19.jar:?]
>
> at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor.access$1200(AbstractPollingIoProcessor.java:68) 
> [mina-core-2.0.19.jar:?]
>
> at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1242) 
> [mina-core-2.0.19.jar:?]
>
> at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1231) 
> [mina-core-2.0.19.jar:?]
>
> at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:683) 
> [mina-core-2.0.19.jar:?]
>
> at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64) 
> [mina-core-2.0.19.jar:?]
>
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
> [?:1.8.0-zing_18.06.0.0]
>
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
> [?:1.8.0-zing_18.06.0.0]
>
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0-zing_18.06.0.0]
>
> Caused by: quickfix.ConfigError: Missing ConnectionType
>
> at quickfix.DefaultSessionFactory.create(DefaultSessionFactory.java:102) 
> ~[quickfixj-core-2.1.0.jar:2.1.0]
>
> at 
> quickfix.mina.acceptor.DynamicAcceptorSessionProvider.getSession(DynamicAcceptorSessionProvider.java:148) 
> ~[quickfixj-cor
>
>
> ----
> I find this very strange, as we definitely have the session configuration, and the session 
> configuration specifies the 'ConnectionType' (which is an 'acceptor').
>
> Also, earlier in the log we found the following error:
> ----
>
> 2018-11-19 23:00:34,836|| ERROR |||| org.quickfixj.QFJException: Connector MBean postregistration 
> failed | NioProcessor-23 | q.m.a.AcceptorIoHandler
>
> org.quickfixj.QFJException: Connector MBean postregistration failed
>
> at org.quickfixj.jmx.mbean.connector.ConnectorAdmin.registerSessions(ConnectorAdmin.java:188) 
> ~[quickfixj-core-2.1.0.jar:2.1.0]
>
> at org.quickfixj.jmx.mbean.connector.ConnectorAdmin.lambda$postRegister$0(ConnectorAdmin.java:170) 
> ~[quickfixj-core-2.1.0.jar:2.1.0]
>
> at java.beans.PropertyChangeSupport.fire(PropertyChangeSupport.java:335) ~[?:1.8.0_172]
>
> at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:327) ~[?:1.8.0_172]
>
> at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:263) ~[?:1.8.0_172]
>
> at quickfix.mina.SessionConnector.addDynamicSession(SessionConnector.java:166) 
> ~[quickfixj-core-2.1.0.jar:2.1.0]
>
> at 
> quickfix.mina.acceptor.DynamicAcceptorSessionProvider.getSession(DynamicAcceptorSessionProvider.java:150) 
> ~[quickfixj-core-2.1.0.jar:2.1.0]
>
> at quickfix.mina.acceptor.AcceptorIoHandler.findQFSession(AcceptorIoHandler.java:118) 
> ~[quickfixj-core-2.1.0.jar:2.1.0]
>
> at quickfix.mina.AbstractIoHandler.messageReceived(AbstractIoHandler.java:129) 
> ~[quickfixj-core-2.1.0.jar:2.1.0]
>
> at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:997) 
> ~[mina-core-2.0.19.jar:?]
>
> at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641) 
> [mina-core-2.0.19.jar:?]
>
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48) 
> [mina-core-2.0.19.jar:?]
>
> at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1114) 
> [mina-core-2.0.19.jar:?]
>
> at 
> org.apache.mina.filter.codec.ProtocolCodecFilter$ProtocolDecoderOutputImpl.flush(ProtocolCodecFilter.java:437) 
> [mina-core-2.0.19.jar:?]
>
> at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:256) 
> [mina-core-2.0.19.jar:?]
>
> at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641) 
> [mina-core-2.0.19.jar:?]
>
> at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48) 
> [mina-core-2.0.19.jar:?]
>
> at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1114) 
> [mina-core-2.0.19.jar:?]
>
> at org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:121) 
> [mina-core-2.0.19.jar:?]
>
> at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641) 
> [mina-core-2.0.19.jar:?]
>
> at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:634) 
> [mina-core-2.0.19.jar:?]
>
> at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:539) 
> [mina-core-2.0.19.jar:?]
>
> at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor.access$1200(AbstractPollingIoProcessor.java:68) 
> [mina-core-2.0.19.jar:?]
>
> at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1242) 
> [mina-core-2.0.19.jar:?]
>
> at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1231) 
> [mina-core-2.0.19.jar:?]
>
> at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:683) 
> [mina-core-2.0.19.jar:?]
>
> at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64) 
> [mina-core-2.0.19.jar:?]
>
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_172]
>
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_172]
>
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_172]
>
> Caused by: javax.management.InstanceAlreadyExistsException: 
> org.quickfixj:type=Settings,beginString=FIX.4.2,senderCompID=AU_MD,targetCompID=esp-peak-33
>
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437) ~[?:1.8.0_172]
>
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898) 
> ~[?:1.8.0_172]
>
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966) 
> ~[?:1.8.0_172]
>
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900) 
> ~[?:1.8.0_172]
>
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324) 
> ~[?:1.8.0_172]
>
> at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522) ~[?:1.8.0_172]
>
> at org.quickfixj.jmx.JmxExporter.registerMBean(JmxExporter.java:131) ~[quickfixj-core-2.1.0.jar:2.1.0]
>
> at org.quickfixj.jmx.mbean.session.SessionJmxExporter.register(SessionJmxExporter.java:45) 
> ~[quickfixj-core-2.1.0.jar:2.1.0]
>
> at org.quickfixj.jmx.mbean.connector.ConnectorAdmin.registerSessions(ConnectorAdmin.java:181) 
> ~[quickfixj-core-2.1.0.jar:2.1.0]
>
> ... 29 more
>
>
> ---
>
> I'm not 100% sure if they are related though (i..e whether the mbean registration failure caused 
> the  session configuration error).
>
> I know that we can change the JMX Exporter behaviour to get around the jmx registration. But right 
> now it is set as default (which I believe is 'REGISTRATION_FAIL_ON_EXISTING').
>
>
> Thanks in advance!
>
>
>
> -- 
> Best regards,
>
>
> Alex Wibowo
>
>

-- 
Christoph John
Software Engineering
T +49 241 557080-28
chr...@ma...

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald

Re: [Quickfixj-users] Initiator failover due to acceptor compID already in use

[Philip W. <Phi...@fl...>]

This does not seem like desired behaviour for most people. I would not expect my system to failover to a DR because the CompID was in use.

That's a pretty blatant architectural design problem, not a network issue.

Secondary links are designed for network problems, not application layer problems.


Why do you need this behaviour?


Philip Whitehouse

________________________________
From: Tsz Shun Chow <jas...@gm...>
Sent: 19 November 2018 11:20:47
To: qui...@li...
Subject: [Quickfixj-users] Initiator failover due to acceptor compID already in use

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

[Quickfixj-users] SessionSettings gets cleared out

[Alex W. <ale...@gm...>]

Hi,

We have been using DynamicAcceptorSessionProvider in our project for quite
sometime now.
After a recent upgrade to Quickfix 2.1.0 (from 1.5.3), we saw some errors
that I believe is caused by Quickfix being unable to find the session
settings.
The stack trace looks like below:
-----

2018-11-19 00:01:13,236|| ERROR |||| org.quickfixj.QFJException:
quickfix.ConfigError: Missing ConnectionType | NioProcessor-23 |
q.m.a.AcceptorIoHandler

org.quickfixj.QFJException: quickfix.ConfigError: Missing ConnectionType

        at
quickfix.mina.acceptor.DynamicAcceptorSessionProvider.getSession(DynamicAcceptorSessionProvider.java:153)
~[quickfixj-core-2.1.0.jar:2.1.0]

        at
quickfix.mina.acceptor.AcceptorIoHandler.findQFSession(AcceptorIoHandler.java:118)
~[quickfixj-core-2.1.0.jar:2.1.0]

        at
quickfix.mina.AbstractIoHandler.messageReceived(AbstractIoHandler.java:129)
~[quickfixj-core-2.1.0.jar:2.1.0]

       at
org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:997)
~[mina-core-2.0.19.jar:?]

        at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641)
[mina-core-2.0.19.jar:?]

        at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48)
[mina-core-2.0.19.jar:?]

        at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1114)
[mina-core-2.0.19.jar:?]

        at
org.apache.mina.filter.codec.ProtocolCodecFilter$ProtocolDecoderOutputImpl.flush(ProtocolCodecFilter.java:437)
[mina-core-2.0.19.jar:?]

        at
org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:256)
[mina-core-2.0.19.jar:?]

        at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641)
[mina-core-2.0.19.jar:?]

        at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48)
[mina-core-2.0.19.jar:?]

        at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1114)
[mina-core-2.0.19.jar:?]

        at
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:121)
[mina-core-2.0.19.jar:?]

        at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641)
[mina-core-2.0.19.jar:?]

        at
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:634)
[mina-core-2.0.19.jar:?]

        at
org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:539)
[mina-core-2.0.19.jar:?]

        at
org.apache.mina.core.polling.AbstractPollingIoProcessor.access$1200(AbstractPollingIoProcessor.java:68)
[mina-core-2.0.19.jar:?]

        at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1242)
[mina-core-2.0.19.jar:?]

        at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1231)
[mina-core-2.0.19.jar:?]

        at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:683)
[mina-core-2.0.19.jar:?]

        at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
[mina-core-2.0.19.jar:?]

        at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[?:1.8.0-zing_18.06.0.0]

        at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[?:1.8.0-zing_18.06.0.0]

        at java.lang.Thread.run(Thread.java:748) [?:1.8.0-zing_18.06.0.0]

Caused by: quickfix.ConfigError: Missing ConnectionType

        at
quickfix.DefaultSessionFactory.create(DefaultSessionFactory.java:102)
~[quickfixj-core-2.1.0.jar:2.1.0]

        at
quickfix.mina.acceptor.DynamicAcceptorSessionProvider.getSession(DynamicAcceptorSessionProvider.java:148)
~[quickfixj-cor

----
I find this very strange, as we definitely have the session configuration,
and the session configuration specifies the 'ConnectionType' (which is an
'acceptor').

Also, earlier in the log we found the following error:
----

2018-11-19 23:00:34,836|| ERROR |||| org.quickfixj.QFJException: Connector
MBean postregistration failed | NioProcessor-23 | q.m.a.AcceptorIoHandler

org.quickfixj.QFJException: Connector MBean postregistration failed

          at
org.quickfixj.jmx.mbean.connector.ConnectorAdmin.registerSessions(ConnectorAdmin.java:188)
~[quickfixj-core-2.1.0.jar:2.1.0]

          at
org.quickfixj.jmx.mbean.connector.ConnectorAdmin.lambda$postRegister$0(ConnectorAdmin.java:170)
~[quickfixj-core-2.1.0.jar:2.1.0]

          at
java.beans.PropertyChangeSupport.fire(PropertyChangeSupport.java:335)
~[?:1.8.0_172]

          at
java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:327)
~[?:1.8.0_172]

          at
java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:263)
~[?:1.8.0_172]

          at
quickfix.mina.SessionConnector.addDynamicSession(SessionConnector.java:166)
~[quickfixj-core-2.1.0.jar:2.1.0]

          at
quickfix.mina.acceptor.DynamicAcceptorSessionProvider.getSession(DynamicAcceptorSessionProvider.java:150)
~[quickfixj-core-2.1.0.jar:2.1.0]

          at
quickfix.mina.acceptor.AcceptorIoHandler.findQFSession(AcceptorIoHandler.java:118)
~[quickfixj-core-2.1.0.jar:2.1.0]

          at
quickfix.mina.AbstractIoHandler.messageReceived(AbstractIoHandler.java:129)
~[quickfixj-core-2.1.0.jar:2.1.0]

          at
org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:997)
~[mina-core-2.0.19.jar:?]

          at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641)
[mina-core-2.0.19.jar:?]

          at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48)
[mina-core-2.0.19.jar:?]

          at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1114)
[mina-core-2.0.19.jar:?]

          at
org.apache.mina.filter.codec.ProtocolCodecFilter$ProtocolDecoderOutputImpl.flush(ProtocolCodecFilter.java:437)
[mina-core-2.0.19.jar:?]

          at
org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:256)
[mina-core-2.0.19.jar:?]

          at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641)
[mina-core-2.0.19.jar:?]

          at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48)
[mina-core-2.0.19.jar:?]

          at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1114)
[mina-core-2.0.19.jar:?]

          at
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:121)
[mina-core-2.0.19.jar:?]

          at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641)
[mina-core-2.0.19.jar:?]

          at
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:634)
[mina-core-2.0.19.jar:?]

          at
org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:539)
[mina-core-2.0.19.jar:?]

          at
org.apache.mina.core.polling.AbstractPollingIoProcessor.access$1200(AbstractPollingIoProcessor.java:68)
[mina-core-2.0.19.jar:?]

          at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1242)
[mina-core-2.0.19.jar:?]

          at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1231)
[mina-core-2.0.19.jar:?]

          at
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:683)
[mina-core-2.0.19.jar:?]

          at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
[mina-core-2.0.19.jar:?]

          at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[?:1.8.0_172]

          at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[?:1.8.0_172]

          at java.lang.Thread.run(Thread.java:748) [?:1.8.0_172]

Caused by: javax.management.InstanceAlreadyExistsException:
org.quickfixj:type=Settings,beginString=FIX.4.2,senderCompID=AU_MD,targetCompID=esp-peak-33

          at
com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
~[?:1.8.0_172]

          at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
~[?:1.8.0_172]

          at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
~[?:1.8.0_172]

          at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
~[?:1.8.0_172]

          at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
~[?:1.8.0_172]

          at
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
~[?:1.8.0_172]

          at
org.quickfixj.jmx.JmxExporter.registerMBean(JmxExporter.java:131)
~[quickfixj-core-2.1.0.jar:2.1.0]

          at
org.quickfixj.jmx.mbean.session.SessionJmxExporter.register(SessionJmxExporter.java:45)
~[quickfixj-core-2.1.0.jar:2.1.0]

          at
org.quickfixj.jmx.mbean.connector.ConnectorAdmin.registerSessions(ConnectorAdmin.java:181)
~[quickfixj-core-2.1.0.jar:2.1.0]

          ... 29 more

---

I'm not 100% sure if they are related though (i..e whether the mbean
registration failure caused the  session configuration error).

I know that we can change the JMX Exporter behaviour to get around the jmx
registration. But right now it is set as default (which I believe is
'REGISTRATION_FAIL_ON_EXISTING').


Thanks in advance!



-- 
Best regards,


Alex Wibowo

[Quickfixj-users] Initiator failover due to acceptor compID already in use

[Tsz S. C. <jas...@gm...>]

Hi all,

We have recently found a problem that Initiator failover was stuck with the
first address when acceptor compID already in use by another initiator.

It seem to be related to this, though I think the change only exposed the
bug, not created it.

https://github.com/quickfix-j/quickfixj/commit/622b858d4a6d972b0d2006b5029f2be354d1dcdc

In the case of targetCompID in use, the session was connected and active,
so the address index set to one, even it was dropped afterwards. Then the
initiator will try and fail forever until the session of the targetCompID
is available again.

How could the initiator detect the targetCompID in use and therefore could
try next address in the list?

Cheers
Jason

Re: [Quickfixj-users] Any interest in these artifacts?

[Colin D. <co...@ma...>]

Thanks, Chris, maybe I'll just spend the time I was going to spend on 
pull requests reading the doc instead and save us all some trouble :-)

For the dynamic sessions, at last check (1.6.3), the problem was that 
sessions could not be deleted completely. Even if you thought you were 
removing the session, the engine would still allow a reconnection until 
restart. If the intent of the current implementation is to completely 
remove the session, then I'll verify that it works now. If it doesn't, 
I'll treat it as a defect rather than a new feature and look at fixing 
the current implementation instead of adding new.

On 11/16/18 3:01 AM, Christoph John wrote:
> Hi Colin,
>
> thank you, great idea!
>
> NullLog: this is already implemented, kind of. If you pass "null" as 
> LogFactory to the Session it will default to a NullLog (private class 
> in SessionState). But I have nothing against making this a separate 
> class to have it more explicit.
>
> Dynamic Sessions: isn't this already implemented? Or is the QFJ 
> implementation lacking something?
>
> Promiscuous Acceptor Session Provider: I also thought that this is 
> already implemented. 
> https://www.quickfixj.org/usermanual/2.1.0/usage/acceptor_dynamic.html
> But I just realised that the settings are not part of the 
> configuration html page so it is easy to overlook.
>
> Hibernate: although not using it myself I'd be interested in the code. 
> But as Philip said it introduces a dependency. On the other hand we 
> already have a SleepycatStore (don't know if someone uses it) that 
> already introduced a dependency. It is marked as optional but of 
> course you need it when compiling.
>
> Cheers,
> Chris.
>
>
> On 15/11/2018 17:53, Colin DuPlantis wrote:
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> We're in the process of moving a whole bunch of our work to FOSS, 
>> including some modifications/enhancements to QFJ. A lot of these are 
>> very specialized to our needs and might not be useful or interesting, 
>> but, I thought I'd float a list here and see if anybody saluted. If 
>> there is interest, I will work on some pull requests.
>>
>> - Hibernate Message Store (in-memory store backed by async 
>> Hibnernate-based persistent store)
>>
>> - NullLogFactory (for testing or quick apps)
>>
>> - RecordingLog (selectively records FIX messages to the database)
>>
>> - Dynamic Sessions (adds and removes sessions at runtime)
>>
>> - Promiscuous Acceptor Session Provider (creates new sessions for 
>> each acceptor session connect attempt)
>>
>>
>
> -- 
> Christoph John
> Software Engineering
> T +49 241 557080-28
> chr...@ma...
>
> MACD GmbH
> Oppenhoffallee 103
> 52066 Aachen, Germany
> www.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald

-- 
Colin DuPlantis
Chief Architect, Marketcetera
Download, Run, Trade
888.868.4884 +1.541.306.6556
http://www.marketcetera.org

Re: [Quickfixj-users] Any interest in these artifacts?

[Christoph J. <chr...@ma...>]

Never mind. As I mentioned some of the behaviour is not very good documented, if at all. :)

Re session deletion: it could be that this has been fixed with 
https://github.com/quickfix-j/quickfixj/pull/175 in 2.1.0. Not sure, but sounds like the problem you 
were having.

Cheers,
Chris.


On 16/11/2018 16:44, Colin DuPlantis wrote:
>
> Thanks, Chris, maybe I'll just spend the time I was going to spend on pull requests reading the 
> doc instead and save us all some trouble :-)
>
> For the dynamic sessions, at last check (1.6.3), the problem was that sessions could not be 
> deleted completely. Even if you thought you were removing the session, the engine would still 
> allow a reconnection until restart. If the intent of the current implementation is to completely 
> remove the session, then I'll verify that it works now. If it doesn't, I'll treat it as a defect 
> rather than a new feature and look at fixing the current implementation instead of adding new.
>
> On 11/16/18 3:01 AM, Christoph John wrote:
>> Hi Colin,
>>
>> thank you, great idea!
>>
>> NullLog: this is already implemented, kind of. If you pass "null" as LogFactory to the Session it 
>> will default to a NullLog (private class in SessionState). But I have nothing against making this 
>> a separate class to have it more explicit.
>>
>> Dynamic Sessions: isn't this already implemented? Or is the QFJ implementation lacking something?
>>
>> Promiscuous Acceptor Session Provider: I also thought that this is already implemented. 
>> https://www.quickfixj.org/usermanual/2.1.0/usage/acceptor_dynamic.html
>> But I just realised that the settings are not part of the configuration html page so it is easy 
>> to overlook.
>>
>> Hibernate: although not using it myself I'd be interested in the code. But as Philip said it 
>> introduces a dependency. On the other hand we already have a SleepycatStore (don't know if 
>> someone uses it) that already introduced a dependency. It is marked as optional but of course you 
>> need it when compiling.
>>
>> Cheers,
>> Chris.
>>
>>
>> On 15/11/2018 17:53, Colin DuPlantis wrote:
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>
>>>
>>> We're in the process of moving a whole bunch of our work to FOSS, including some 
>>> modifications/enhancements to QFJ. A lot of these are very specialized to our needs and might 
>>> not be useful or interesting, but, I thought I'd float a list here and see if anybody saluted. 
>>> If there is interest, I will work on some pull requests.
>>>
>>> - Hibernate Message Store (in-memory store backed by async Hibnernate-based persistent store)
>>>
>>> - NullLogFactory (for testing or quick apps)
>>>
>>> - RecordingLog (selectively records FIX messages to the database)
>>>
>>> - Dynamic Sessions (adds and removes sessions at runtime)
>>>
>>> - Promiscuous Acceptor Session Provider (creates new sessions for each acceptor session connect 
>>> attempt)
>>>
>>>
>>
>> -- 
>> Christoph John
>> Software Engineering
>> T +49 241 557080-28
>> chr...@ma...
>>
>> MACD GmbH
>> Oppenhoffallee 103
>> 52066 Aachen, Germany
>> www.macd.com
>>
>> Amtsgericht Aachen: HRB 8151
>> Ust.-Id: DE 813021663
>> Geschäftsführer: George Macdonald
> -- 
> Colin DuPlantis
> Chief Architect, Marketcetera
> Download, Run, Trade
> 888.868.4884 +1.541.306.6556
> http://www.marketcetera.org

-- 
Christoph John
Software Engineering
T +49 241 557080-28
chr...@ma...

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald