From users-return-49857-archive-asf-public=cust-asf.ponee.io@activemq.apache.org Tue Apr 17 19:55:25 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 84CA9180649 for ; Tue, 17 Apr 2018 19:55:24 +0200 (CEST) Received: (qmail 19120 invoked by uid 500); 17 Apr 2018 17:55:18 -0000 Mailing-List: contact users-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@activemq.apache.org Delivered-To: mailing list users@activemq.apache.org Received: (qmail 19109 invoked by uid 99); 17 Apr 2018 17:55:18 -0000 Received: from mail-relay.apache.org (HELO mailrelay1-lw-us.apache.org) (207.244.88.152) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Apr 2018 17:55:18 +0000 Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id A65842B9F for ; Tue, 17 Apr 2018 17:55:17 +0000 (UTC) Received: by mail-oi0-f41.google.com with SMTP id y20-v6so7335667oix.5 for ; Tue, 17 Apr 2018 10:55:17 -0700 (PDT) X-Gm-Message-State: ALQs6tCFa2F/ax1Q62G/VrAFvXQnBoUwIUAb2UBTUHnxnZeGgLxlMOr2 IOwKKreWxuvj1xrqlkw5lYfmkKsFX/9Z7hyTbBDdXQ== X-Google-Smtp-Source: AIpwx4+JkH0+CfGe2WPPc6rGQbyqfbHtXPxWS7C/h4ZEt2gcP3zw+zxSr94zcWoLin/ZQZ8rOD6AKDqCsEVN/hbZv94= X-Received: by 2002:aca:413:: with SMTP id 19-v6mr1764853oie.134.1523987716715; Tue, 17 Apr 2018 10:55:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.80.19 with HTTP; Tue, 17 Apr 2018 10:55:16 -0700 (PDT) In-Reply-To: <1523947444420-0.post@n4.nabble.com> References: <1523947444420-0.post@n4.nabble.com> From: Justin Bertram Date: Tue, 17 Apr 2018 12:55:16 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: 1. Windows Platform support, 2.Net Client examples for AMQP Apache ActiveMQ Artemis 3. Persistent Storage To: users@activemq.apache.org Content-Type: multipart/alternative; boundary="0000000000007f5420056a0f0a75" --0000000000007f5420056a0f0a75 Content-Type: text/plain; charset="UTF-8" > How good is the support for Windows Platform I'm not sure what you mean here specifically so I'll just provide a general answer. Artemis is written in Java so it runs on any platform with a JVM - Windows included. > Do we have all equivalent examples for AMQP DotNet which are given for JMS API No. > Do we see any advantages of File system vs database persistence, One could be speed... Speed is certainly an advantage of the file-based journal vs. database. Here are a few other potential advantages: - Cost. There is no need to purchase a database solution or pay for support. There is also no need to pay for hardware for the database to run on. - Simplicity. There is no need to deploy database drivers or configure JDBC connection details on the broker, configure the database, etc. > ... But when it comes to security of stored messages, backup and restore. Is there no security with filesystem like we have have for databases. No security for file-systems? Security for file-systems is typically a core function of the operating system. It's extremely easy and common to set up file-system security in Linux environments. I assume the same is true in Windows. It's worth noting that in almost every case the database itself will store its information on the file-system so any lack of security would impact both the file-based journal and a database. > Can anyone who have access to file directly read messages from it by opening in a text editor... The data stored in the file-based journal is binary and therefore not human readable. A user couldn't open the journal in a text editor and simply read the data. That said, it's also not encrypted so users with access could theoretically get the information. That's why operating systems provide things like role-based access control for file-systems. As before, it's worth noting here that the same problem applies to any database which stores its data on the file-system. Anybody with access could theoretically get the data. > How is the backup mechanism for it... Simply copy the journal files to a backup. They are just files, after all. > Does it support restoring similar to SQL Databases If something happens to the journal (e.g. hard drive crash) simply stop the broker and restore the journal files from the backup. I'm not terribly familiar with databases these days so I'm not sure how it compares, but restoring files from a backup can be as simple as a single command. > In case of a hard drive crash, parts of SQL Databases can still be recovered, Do we have similar possibilities for filesystem ? If parts of a journal file are corrupted for some reason that will not invalidate the entire journal so it will still be possible to recover data. > Can we rely on the filesystem for Message storage where loss of data is critical ? I'm not sure the journal itself has much control over this. I believe this depends more on your infrastructure to support data availability (e.g. RAID, regular backups, etc.). Hope that helps. Justin On Tue, Apr 17, 2018 at 1:44 AM, pathaari wrote: > Hello > > 1. How good is the support for Windows Platform > > 2. I have tried to look for all examples of AMQP Dot Net, But I can find > just the hello world example, Rest entire documentation is with JMS API's > Do we have all equivalent examples for AMQP DotNet which are given for JMS > API > > Next > 3. For persistence its mentioned, Apache ActiveMQ Artemis supports JDBC for > db vendors like PostgreSQL, MYSQL, But JDBC persistent store is still under > development. But the default is File Journal, > > Do we see any advantages of File system vs database persistence, One could > be speed > But when it comes to security of stored messages, backup and restore > > Is there no security with filesystem like we have have for databases. > Can anyone who have access to file directly read messages from it by > opening > in a text editor > How is the backup mechanism for it > Does it support restoring similar to SQL Databases > In case of a hard drive crash, parts of SQL Databases can still be > recovered, Do we have similar possibilities for filesystem ? > Can we rely on the filesystem for Message storage where loss of data is > critical ? > > Thanks > > > > > -- > Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User- > f2341805.html > --0000000000007f5420056a0f0a75--