Quantcast

quick poll: message store

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

quick poll: message store

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


Hi,

just a question out of curiosity: are you using a FileStore, JdbcStore or a custom built message
store with QFJ?

Thanks,
Chris.

--
Christoph John
Development & Support
Direct: +49 241 557080-28
Mailto:[hidden email]
       


http://www.macd.com <http://www.macd.com/>
----------------------------------------------------------------------------------------------------
       
----------------------------------------------------------------------------------------------------
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: +49 241 557080-0 | Fax: +49 241 557080-10
         Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald
----------------------------------------------------------------------------------------------------
       
----------------------------------------------------------------------------------------------------

take care of the environment - print only if necessary

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: quick poll: message store

Daniil Sosonkin-2
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Custom built RedisStore. Before that - JdbcStore.

On 1/30/2017 9:58 AM, Christoph John wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi,
>
> just a question out of curiosity: are you using a FileStore, JdbcStore or a custom built message
> store with QFJ?
>
> Thanks,
> Chris.
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: quick poll: message store

Guido Medina
In reply to this post by Christoph John
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Hi Chris,

I'm of the opinion that for many messages scenarios like market data for example no storage should be used (in my case the new NoopStore)
Needs vary, I believe people will find FileStore vs JdbcStore the fastest if using SSDs but if distributed scenario is needed then JdbcStore is preferred.

But for newer systems you will probably find people using Distributed KV stores, like Hazelcast or Cassandra or Riak,
anything that can store these messages in memory and distributed as KV systems will be faster for KV scenarions like key = (session_id, message_id)

HTH,

Guido.

On Mon, Jan 30, 2017 at 2:58 PM, Christoph John <[hidden email]> wrote:
QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/ QuickFIX/J" rel="noreferrer" target="_blank">http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi,

just a question out of curiosity: are you using a FileStore, JdbcStore or a custom built message
store with QFJ?

Thanks,
Chris.

--
Christoph John
Development & Support
Direct: <a href="tel:%2B49%20241%20557080-28" value="+4924155708028">+49 241 557080-28
Mailto:[hidden email]



http://www.macd.com <http://www.macd.com/>
----------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: <a href="tel:%2B49%20241%20557080-0" value="+492415570800">+49 241 557080-0 | Fax: <a href="tel:%2B49%20241%20557080-10" value="+4924155708010">+49 241 557080-10
         Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald
----------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------

take care of the environment - print only if necessary

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: quick poll: message store

Colin DuPlantis
In reply to this post by Christoph John
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Custom-built here, storing in the DB. We use Hibernate, so we have a
Hibernate-compatible datastore. In addition to having Hibernate create
and validate the tables and indices for us, we also batch up inserts and
make the writes asynchronously.


On 01/30/2017 06:58 AM, Christoph John wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi,
>
> just a question out of curiosity: are you using a FileStore, JdbcStore or a custom built message
> store with QFJ?
>
> Thanks,
> Chris.
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: quick poll: message store

Colin DuPlantis
In reply to this post by Guido Medina
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Guido,

We've experimented with Hazelcast message stores but found Hcast to be flaky and unreliable around adding members to an active cluster, where active is defined as using operations like Lock, ReplicatedMap, or ExecutorService, anything that hits all the nodes in the cluster just as one is starting up. Have you, by any chance, run into anything similar? The problem presents as one or more members locking up forever and ever until executed. We haven't been able to reproduce it outside of production (of course) and Hazelcast hasn't been very helpful, perhaps not unreasonably. Very frustrating.

Thanks.

- Colin


On 01/30/2017 07:06 AM, Guido Medina wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/




Hi Chris,

I'm of the opinion that for many messages scenarios like market data for example no storage should be used (in my case the new NoopStore)
Needs vary, I believe people will find FileStore vs JdbcStore the fastest if using SSDs but if distributed scenario is needed then JdbcStore is preferred.

But for newer systems you will probably find people using Distributed KV stores, like Hazelcast or Cassandra or Riak,
anything that can store these messages in memory and distributed as KV systems will be faster for KV scenarions like key = (session_id, message_id)

HTH,

Guido.

On Mon, Jan 30, 2017 at 2:58 PM, Christoph John <[hidden email]> wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J
Support: http://www.quickfixj.org/support/


Hi,

just a question out of curiosity: are you using a FileStore, JdbcStore or a custom built message
store with QFJ?

Thanks,
Chris.

--
Christoph John
Development & Support
Direct: <a moz-do-not-send="true" href="tel:%2B49%20241%20557080-28" value="+4924155708028">+49 241 557080-28
Mailto:[hidden email]



http://www.macd.com <http://www.macd.com/>
----------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: <a moz-do-not-send="true" href="tel:%2B49%20241%20557080-0" value="+492415570800">+49 241 557080-0 | Fax: <a moz-do-not-send="true" href="tel:%2B49%20241%20557080-10" value="+4924155708010">+49 241 557080-10
         Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald
----------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------

take care of the environment - print only if necessary

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: quick poll: message store

Guido Medina
In reply to this post by Colin DuPlantis
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



I have been using Hazelcast for something else and here is my experience so far and advises I can give you so far:
1) Try to keep your cluster static, we have a list of members, no auto-discovery, etc.
2) I was connecting to the cluster using the client but when there was a network problem my client would go crazy with a split brain situation so I solved it by treating the application as a cluster member too, meaning, keep list of point 1 static and the other members as dynamic.

What version of Hazelcast? I'm using the old 3.5.5 with Java 8 (I would go to 3.7.x but a senior member of my team doesn't want to)
So basically static list of well known TCP/IP members should do the job, the variable members don't need to be on that list.

I don't use distributed locks, only Maps and Queues by simply putting/removing stuff.

HTH,

Guido.

On Mon, Jan 30, 2017 at 3:07 PM, Colin DuPlantis <[hidden email]> wrote:
QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/ QuickFIX/J" rel="noreferrer" target="_blank">http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Custom-built here, storing in the DB. We use Hibernate, so we have a
Hibernate-compatible datastore. In addition to having Hibernate create
and validate the tables and indices for us, we also batch up inserts and
make the writes asynchronously.


On 01/30/2017 06:58 AM, Christoph John wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi,
>
> just a question out of curiosity: are you using a FileStore, JdbcStore or a custom built message
> store with QFJ?
>
> Thanks,
> Chris.
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: quick poll: message store

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



We're using 3.6.2, but upgrading to the most recent hasn't helped. We do use a static list of IP members, but see the problem when a member is removed and re-added. I've dug some into the Hcast code and the issue occurs during a synchronized block that is executed when the member is re-added and an Execute (etc) call is made at the same time. I have a sneaking suspicion that the problem occurs only when using the Hazelcast-Spring extension to create the cluster using Spring configuration files, but have no proof to back that up.

We don't use clients, though. We have all members just join the cluster.

Anyway, thanks for the response.

- Colin


On 01/30/2017 07:31 AM, Guido Medina wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/




I have been using Hazelcast for something else and here is my experience so far and advises I can give you so far:
1) Try to keep your cluster static, we have a list of members, no auto-discovery, etc.
2) I was connecting to the cluster using the client but when there was a network problem my client would go crazy with a split brain situation so I solved it by treating the application as a cluster member too, meaning, keep list of point 1 static and the other members as dynamic.

What version of Hazelcast? I'm using the old 3.5.5 with Java 8 (I would go to 3.7.x but a senior member of my team doesn't want to)
So basically static list of well known TCP/IP members should do the job, the variable members don't need to be on that list.

I don't use distributed locks, only Maps and Queues by simply putting/removing stuff.

HTH,

Guido.

On Mon, Jan 30, 2017 at 3:07 PM, Colin DuPlantis <[hidden email]> wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Custom-built here, storing in the DB. We use Hibernate, so we have a
Hibernate-compatible datastore. In addition to having Hibernate create
and validate the tables and indices for us, we also batch up inserts and
make the writes asynchronously.


On 01/30/2017 06:58 AM, Christoph John wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi,
>
> just a question out of curiosity: are you using a FileStore, JdbcStore or a custom built message
> store with QFJ?
>
> Thanks,
> Chris.
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: quick poll: message store

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



Hazelcast Java main should be sufficient, I don't use it with anything else (i.e.: Spring, etc), I simply invoke its Java main which can be interrupted or use to create a Linux service,
also; take into consideration the cost of re-starting a member, don't just start a member you remove, it has to propagate the removal action and then started,
meaning, stop it, wait few seconds and then start it, that issue is quite common among distributed cluster members like akka-cluster, hazelcast, etc,

or at least that's what I have come up as a conclusion, some people even kill the Java process which is bad,
Hazelcast or any other dist cluster should be allowed to leave the cluster properly before starting the same instance at the same port again.

HTH,

Guido.

On Mon, Jan 30, 2017 at 3:36 PM, Colin DuPlantis <[hidden email]> wrote:
QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/ QuickFIX/J" rel="noreferrer" target="_blank">http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



We're using 3.6.2, but upgrading to the most recent hasn't helped. We do use a static list of IP members, but see the problem when a member is removed and re-added. I've dug some into the Hcast code and the issue occurs during a synchronized block that is executed when the member is re-added and an Execute (etc) call is made at the same time. I have a sneaking suspicion that the problem occurs only when using the Hazelcast-Spring extension to create the cluster using Spring configuration files, but have no proof to back that up.

We don't use clients, though. We have all members just join the cluster.

Anyway, thanks for the response.

- Colin


On 01/30/2017 07:31 AM, Guido Medina wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/




I have been using Hazelcast for something else and here is my experience so far and advises I can give you so far:
1) Try to keep your cluster static, we have a list of members, no auto-discovery, etc.
2) I was connecting to the cluster using the client but when there was a network problem my client would go crazy with a split brain situation so I solved it by treating the application as a cluster member too, meaning, keep list of point 1 static and the other members as dynamic.

What version of Hazelcast? I'm using the old 3.5.5 with Java 8 (I would go to 3.7.x but a senior member of my team doesn't want to)
So basically static list of well known TCP/IP members should do the job, the variable members don't need to be on that list.

I don't use distributed locks, only Maps and Queues by simply putting/removing stuff.

HTH,

Guido.

On Mon, Jan 30, 2017 at 3:07 PM, Colin DuPlantis <[hidden email]> wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Custom-built here, storing in the DB. We use Hibernate, so we have a
Hibernate-compatible datastore. In addition to having Hibernate create
and validate the tables and indices for us, we also batch up inserts and
make the writes asynchronously.


On 01/30/2017 06:58 AM, Christoph John wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi,
>
> just a question out of curiosity: are you using a FileStore, JdbcStore or a custom built message
> store with QFJ?
>
> Thanks,
> Chris.
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: quick poll: message store

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



Yes, ideally, the exit and entrance should be well-behaved, however, when testing failover use cases, abrupt exit must be handled. This is the type of scenario where we see the problem.


On 01/30/2017 07:42 AM, Guido Medina wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/




Hazelcast Java main should be sufficient, I don't use it with anything else (i.e.: Spring, etc), I simply invoke its Java main which can be interrupted or use to create a Linux service,
also; take into consideration the cost of re-starting a member, don't just start a member you remove, it has to propagate the removal action and then started,
meaning, stop it, wait few seconds and then start it, that issue is quite common among distributed cluster members like akka-cluster, hazelcast, etc,

or at least that's what I have come up as a conclusion, some people even kill the Java process which is bad,
Hazelcast or any other dist cluster should be allowed to leave the cluster properly before starting the same instance at the same port again.

HTH,

Guido.

On Mon, Jan 30, 2017 at 3:36 PM, Colin DuPlantis <[hidden email]> wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



We're using 3.6.2, but upgrading to the most recent hasn't helped. We do use a static list of IP members, but see the problem when a member is removed and re-added. I've dug some into the Hcast code and the issue occurs during a synchronized block that is executed when the member is re-added and an Execute (etc) call is made at the same time. I have a sneaking suspicion that the problem occurs only when using the Hazelcast-Spring extension to create the cluster using Spring configuration files, but have no proof to back that up.

We don't use clients, though. We have all members just join the cluster.

Anyway, thanks for the response.

- Colin


On 01/30/2017 07:31 AM, Guido Medina wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


I have been using Hazelcast for something else and here is my experience so far and advises I can give you so far:
1) Try to keep your cluster static, we have a list of members, no auto-discovery, etc.
2) I was connecting to the cluster using the client but when there was a network problem my client would go crazy with a split brain situation so I solved it by treating the application as a cluster member too, meaning, keep list of point 1 static and the other members as dynamic.
What version of Hazelcast? I'm using the old 3.5.5 with Java 8 (I would go to 3.7.x but a senior member of my team doesn't want to)
So basically static list of well known TCP/IP members should do the job, the variable members don't need to be on that list.
I don't use distributed locks, only Maps and Queues by simply putting/removing stuff.
HTH,
Guido.
On Mon, Jan 30, 2017 at 3:07 PM, Colin DuPlantis <[hidden email]> wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ Custom-built here, storing in the DB. We use Hibernate, so we have a Hibernate-compatible datastore. In addition to having Hibernate create and validate the tables and indices for us, we also batch up inserts and make the writes asynchronously. On 01/30/2017 06:58 AM, Christoph John wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Hi, > > just a question out of curiosity: are you using a FileStore, JdbcStore or a custom built message > store with QFJ? > > Thanks, > Chris. >
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Quickfixj-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quickfixj-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Quickfixj-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quickfixj-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: quick poll: message store

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



Restarting a node is a special case, abrupt existing is handled OK, restarting a node should be timed.

On Mon, Jan 30, 2017 at 3:56 PM, Colin DuPlantis <[hidden email]> wrote:
QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/ QuickFIX/J" rel="noreferrer" target="_blank">http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Yes, ideally, the exit and entrance should be well-behaved, however, when testing failover use cases, abrupt exit must be handled. This is the type of scenario where we see the problem.


On 01/30/2017 07:42 AM, Guido Medina wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/




Hazelcast Java main should be sufficient, I don't use it with anything else (i.e.: Spring, etc), I simply invoke its Java main which can be interrupted or use to create a Linux service,
also; take into consideration the cost of re-starting a member, don't just start a member you remove, it has to propagate the removal action and then started,
meaning, stop it, wait few seconds and then start it, that issue is quite common among distributed cluster members like akka-cluster, hazelcast, etc,

or at least that's what I have come up as a conclusion, some people even kill the Java process which is bad,
Hazelcast or any other dist cluster should be allowed to leave the cluster properly before starting the same instance at the same port again.

HTH,

Guido.

On Mon, Jan 30, 2017 at 3:36 PM, Colin DuPlantis <[hidden email]> wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



We're using 3.6.2, but upgrading to the most recent hasn't helped. We do use a static list of IP members, but see the problem when a member is removed and re-added. I've dug some into the Hcast code and the issue occurs during a synchronized block that is executed when the member is re-added and an Execute (etc) call is made at the same time. I have a sneaking suspicion that the problem occurs only when using the Hazelcast-Spring extension to create the cluster using Spring configuration files, but have no proof to back that up.

We don't use clients, though. We have all members just join the cluster.

Anyway, thanks for the response.

- Colin


On 01/30/2017 07:31 AM, Guido Medina wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


I have been using Hazelcast for something else and here is my experience so far and advises I can give you so far:
1) Try to keep your cluster static, we have a list of members, no auto-discovery, etc.
2) I was connecting to the cluster using the client but when there was a network problem my client would go crazy with a split brain situation so I solved it by treating the application as a cluster member too, meaning, keep list of point 1 static and the other members as dynamic.
What version of Hazelcast? I'm using the old 3.5.5 with Java 8 (I would go to 3.7.x but a senior member of my team doesn't want to)
So basically static list of well known TCP/IP members should do the job, the variable members don't need to be on that list.
I don't use distributed locks, only Maps and Queues by simply putting/removing stuff.
HTH,
Guido.
On Mon, Jan 30, 2017 at 3:07 PM, Colin DuPlantis <[hidden email]> wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ Custom-built here, storing in the DB. We use Hibernate, so we have a Hibernate-compatible datastore. In addition to having Hibernate create and validate the tables and indices for us, we also batch up inserts and make the writes asynchronously. On 01/30/2017 06:58 AM, Christoph John wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Hi, > > just a question out of curiosity: are you using a FileStore, JdbcStore or a custom built message > store with QFJ? > > Thanks, > Chris. >
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Quickfixj-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quickfixj-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Quickfixj-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quickfixj-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: quick poll: message store

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



I agree. Thanks for sharing your thoughts, I appreciate it.


On 01/30/2017 08:09 AM, Guido Medina wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/




Restarting a node is a special case, abrupt existing is handled OK, restarting a node should be timed.

On Mon, Jan 30, 2017 at 3:56 PM, Colin DuPlantis <[hidden email]> wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Yes, ideally, the exit and entrance should be well-behaved, however, when testing failover use cases, abrupt exit must be handled. This is the type of scenario where we see the problem.


On 01/30/2017 07:42 AM, Guido Medina wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hazelcast Java main should be sufficient, I don't use it with anything else (i.e.: Spring, etc), I simply invoke its Java main which can be interrupted or use to create a Linux service,
also; take into consideration the cost of re-starting a member, don't just start a member you remove, it has to propagate the removal action and then started,
meaning, stop it, wait few seconds and then start it, that issue is quite common among distributed cluster members like akka-cluster, hazelcast, etc,
or at least that's what I have come up as a conclusion, some people even kill the Java process which is bad,
Hazelcast or any other dist cluster should be allowed to leave the cluster properly before starting the same instance at the same port again.
HTH,
Guido.
On Mon, Jan 30, 2017 at 3:36 PM, Colin DuPlantis <[hidden email]> wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/

We're using 3.6.2, but upgrading to the most recent hasn't helped. We do use a static list of IP members, but see the problem when a member is removed and re-added. I've dug some into the Hcast code and the issue occurs during a synchronized block that is executed when the member is re-added and an Execute (etc) call is made at the same time. I have a sneaking suspicion that the problem occurs only when using the Hazelcast-Spring extension to create the cluster using Spring configuration files, but have no proof to back that up.

We don't use clients, though. We have all members just join the cluster.

Anyway, thanks for the response.

- Colin

On 01/30/2017 07:31 AM, Guido Medina wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


I have been using Hazelcast for something else and here is my experience so far and advises I can give you so far:
1) Try to keep your cluster static, we have a list of members, no auto-discovery, etc.
2) I was connecting to the cluster using the client but when there was a network problem my client would go crazy with a split brain situation so I solved it by treating the application as a cluster member too, meaning, keep list of point 1 static and the other members as dynamic.
What version of Hazelcast? I'm using the old 3.5.5 with Java 8 (I would go to 3.7.x but a senior member of my team doesn't want to)
So basically static list of well known TCP/IP members should do the job, the variable members don't need to be on that list.
I don't use distributed locks, only Maps and Queues by simply putting/removing stuff.
HTH,
Guido.
On Mon, Jan 30, 2017 at 3:07 PM, Colin DuPlantis <[hidden email]> wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ Custom-built here, storing in the DB. We use Hibernate, so we have a Hibernate-compatible datastore. In addition to having Hibernate create and validate the tables and indices for us, we also batch up inserts and make the writes asynchronously. On 01/30/2017 06:58 AM, Christoph John wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Hi, > > just a question out of curiosity: are you using a FileStore, JdbcStore or a custom built message > store with QFJ? > > Thanks, > Chris. >
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Quickfixj-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quickfixj-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Quickfixj-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quickfixj-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Quickfixj-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quickfixj-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: quick poll: message store

Youyu Shao
In reply to this post by Guido Medina
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


We use FileStore and it works nicely.

Thanks

Youyu

-----Original Message-----
From: Guido Medina [mailto:[hidden email]]
Sent: Monday, January 30, 2017 10:43 AM
To: [hidden email]
Subject: Re: [Quickfixj-users] quick poll: message store

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



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: quick poll: message store

Vipin Chaudhary
In reply to this post by Christoph John
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



We are still in dev, and trying to use custom store where we don't save the complete message, but just store a key, using which we can retrieve the raw data and convert it to fix format again when required.

Thanks
Vipin

On Mon, Jan 30, 2017 at 8:28 PM, Christoph John <[hidden email]> wrote:
QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/ QuickFIX/J" rel="noreferrer" target="_blank">http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi,

just a question out of curiosity: are you using a FileStore, JdbcStore or a custom built message
store with QFJ?

Thanks,
Chris.

--
Christoph John
Development & Support
Direct: +49 241 557080-28
Mailto:[hidden email]



http://www.macd.com <http://www.macd.com/>
----------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: +49 241 557080-0 | Fax: +49 241 557080-10
         Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald
----------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------

take care of the environment - print only if necessary

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: quick poll: message store

Christoph John
In reply to this post by Christoph John
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi,

thanks for your insights. To the guys with Redis or Hazelcast: if I understood correctly then the
FIX message store is shared in a in-memory data structure which is replicated across several nodes.
Is this data also persisted anywhere in case of a total failure? Or is it expected that the whole
cluster will never fail completely?

Thanks,
Chris.


On 30/01/17 15:58, Christoph John wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi,
>
> just a question out of curiosity: are you using a FileStore, JdbcStore or a custom built message
> store with QFJ?
>
> Thanks,
> Chris.
>

--
Christoph John
Development & Support
Direct: +49 241 557080-28
Mailto:[hidden email]
       


http://www.macd.com <http://www.macd.com/>
----------------------------------------------------------------------------------------------------
       
----------------------------------------------------------------------------------------------------
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: +49 241 557080-0 | Fax: +49 241 557080-10
         Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald
----------------------------------------------------------------------------------------------------
       
----------------------------------------------------------------------------------------------------

take care of the environment - print only if necessary

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: quick poll: message store

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



Messages are replicated, usually 2+ nodes are in charged of a hash in the case of KV distributed storage.
The cluster is expected not to fail completely and because messages are in more than 1 node the cluster should recover itself in case of network failure, etc.

HTH,

Guido.

On Tue, Jan 31, 2017 at 11:07 AM, Christoph John <[hidden email]> wrote:
QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/ QuickFIX/J" rel="noreferrer" target="_blank">http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi,

thanks for your insights. To the guys with Redis or Hazelcast: if I understood correctly then the
FIX message store is shared in a in-memory data structure which is replicated across several nodes.
Is this data also persisted anywhere in case of a total failure? Or is it expected that the whole
cluster will never fail completely?

Thanks,
Chris.


On 30/01/17 15:58, Christoph John wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi,
>
> just a question out of curiosity: are you using a FileStore, JdbcStore or a custom built message
> store with QFJ?
>
> Thanks,
> Chris.
>

--
Christoph John
Development & Support
Direct: <a href="tel:%2B49%20241%20557080-28" value="+4924155708028">+49 241 557080-28
Mailto:[hidden email]



http://www.macd.com <http://www.macd.com/>
----------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: <a href="tel:%2B49%20241%20557080-0" value="+492415570800">+49 241 557080-0 | Fax: <a href="tel:%2B49%20241%20557080-10" value="+4924155708010">+49 241 557080-10
         Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald
----------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------

take care of the environment - print only if necessary

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: quick poll: message store

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



It is like MemoryStorage but distributed among several JVMs (usually not on the same physical machine) where the access is as fast as accessing a ConcurrentHashMap with a serialization price to pay.

On Tue, Jan 31, 2017 at 11:35 AM, Guido Medina <[hidden email]> wrote:
Messages are replicated, usually 2+ nodes are in charged of a hash in the case of KV distributed storage.
The cluster is expected not to fail completely and because messages are in more than 1 node the cluster should recover itself in case of network failure, etc.

HTH,

Guido.

On Tue, Jan 31, 2017 at 11:07 AM, Christoph John <[hidden email]> wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J
Support: http://www.quickfixj.org/support/


Hi,

thanks for your insights. To the guys with Redis or Hazelcast: if I understood correctly then the
FIX message store is shared in a in-memory data structure which is replicated across several nodes.
Is this data also persisted anywhere in case of a total failure? Or is it expected that the whole
cluster will never fail completely?

Thanks,
Chris.


On 30/01/17 15:58, Christoph John wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi,
>
> just a question out of curiosity: are you using a FileStore, JdbcStore or a custom built message
> store with QFJ?
>
> Thanks,
> Chris.
>

--
Christoph John
Development & Support
Direct: <a href="tel:%2B49%20241%20557080-28" value="+4924155708028" target="_blank">+49 241 557080-28
Mailto:[hidden email]



http://www.macd.com <http://www.macd.com/>
----------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: <a href="tel:%2B49%20241%20557080-0" value="+492415570800" target="_blank">+49 241 557080-0 | Fax: <a href="tel:%2B49%20241%20557080-10" value="+4924155708010" target="_blank">+49 241 557080-10
         Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald
----------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------

take care of the environment - print only if necessary

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: quick poll: message store

Øyvind Matheson Wergeland
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



JdbcStore.

We don't process many messages, and it is a multi tenant solution with several FIX sessions, so it was the most reliable message store at the time of our original implementation. If I remember correctly, there were problems with FileStore and corrupted files back then.

 -Øyvind

Den 31. jan. 2017 kl. 12.37 skrev Guido Medina <[hidden email]>:

It is like MemoryStorage but distributed among several JVMs (usually not on the same physical machine) where the access is as fast as accessing a ConcurrentHashMap with a serialization price to pay.

On Tue, Jan 31, 2017 at 11:35 AM, Guido Medina <[hidden email]> wrote:
Messages are replicated, usually 2+ nodes are in charged of a hash in the case of KV distributed storage.
The cluster is expected not to fail completely and because messages are in more than 1 node the cluster should recover itself in case of network failure, etc.

HTH,

Guido.

On Tue, Jan 31, 2017 at 11:07 AM, Christoph John <[hidden email]> wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J
Support: http://www.quickfixj.org/support/


Hi,

thanks for your insights. To the guys with Redis or Hazelcast: if I understood correctly then the
FIX message store is shared in a in-memory data structure which is replicated across several nodes.
Is this data also persisted anywhere in case of a total failure? Or is it expected that the whole
cluster will never fail completely?

Thanks,
Chris.


On 30/01/17 15:58, Christoph John wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi,
>
> just a question out of curiosity: are you using a FileStore, JdbcStore or a custom built message
> store with QFJ?
>
> Thanks,
> Chris.
>

--
Christoph John
Development & Support
Direct: <a href="tel:%2B49%20241%20557080-28" value="+4924155708028" target="_blank">+49 241 557080-28
Mailto:[hidden email]



http://www.macd.com <http://www.macd.com/>
----------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: <a href="tel:%2B49%20241%20557080-0" value="+492415570800" target="_blank">+49 241 557080-0 | Fax: <a href="tel:%2B49%20241%20557080-10" value="+4924155708010" target="_blank">+49 241 557080-10
         Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald
----------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------

take care of the environment - print only if necessary

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Loading...