Choose Kafka or Artemis by the integration pattern you must support
Choose Apache Kafka when consumers need to replay history, when several independent applications must read the same events at their own pace, or when much of the integration will run through Kafka Connect source and sink connectors. Choose Apache Artemis when your Java enterprise systems already produce and consume through JMS or Jakarta Messaging, when queue semantics such as point-to-point delivery and per-message acknowledgment are the core need, or when AMQP 1.0, MQTT or STOMP clients must connect to the same broker. Both projects are licensed under Apache-2.0, and Kafka has no paid edition from the project itself, so the decision rests on the integration pattern rather than on license cost.
Three questions settle most of the choice. First, do consumers need replay and long retention? Kafka keeps partitioned records for a configured period and lets a consumer group rewind to an earlier offset, which is the model event sourcing and audit replay depend on. Second, do producers and consumers already speak JMS, AMQP or MQTT? If they do, Artemis avoids rewriting clients. Third, how much of the integration depends on Kafka Connect, which runs in standalone or distributed mode and is managed through a REST API? If your target systems have maintained Kafka connectors, that ecosystem favors Kafka. Write these answers down per integration before you pick a platform for the whole estate.
Test the decision with a short proof of concept. Pick one flow that needs replay and one that needs JMS or a non-Java client, then confirm in your own environment which Kafka client libraries and connectors your Java applications and target systems support, and which Artemis client and protocol features your existing middleware uses. Check the Kafka security settings you will need, including SASL mechanisms and authorization, against your identity standards, and confirm how Artemis handles your OIDC and TLS requirements at the version you plan to run. Mixed estates are common: some teams keep Artemis for transactional queues and use Kafka for the event log, and that split should be a deliberate design, not an accident.
Which platform fits which integration scenario
This table maps five common integration scenarios to the platform that usually fits better and the condition that would flip the choice. Read each row as a starting point, then test it against your own protocols, Java stack and replay requirements.
| Scenario | Better fit | Choose the other platform when |
|---|---|---|
| Replay-driven analytics pipelines | Apache Kafka, because partitioned logs retain events and let consumers re-read from an offset for new analytics or backfills | Consumers only need each message once and nothing requires re-reading history, in which case Artemis queues may be simpler to run |
| JMS-based Java EE or Jakarta EE systems | Apache Artemis, because it implements Jakarta Messaging 3.1 and JMS 2.0 natively, so existing JMS code and application servers need less rework | Your integration is built on Kafka-native clients or Kafka Streams, and rewriting JMS producers and consumers is not justified |
| Mixed AMQP and MQTT device or partner traffic | Apache Artemis, because it speaks AMQP 1.0, MQTT 3.1.1, MQTT 5 and STOMP from one broker with a protocol-agnostic addressing model | Devices or partners only speak the Kafka protocol, or the MQTT volume and session model needs a broker purpose-built for IoT fleets, which you should evaluate separately |
| Kafka Connect-centric data movement | Apache Kafka, because Kafka Connect provides source and sink connectors to move data between Kafka and external systems through a REST-managed runtime | Your data moves mainly through JMS endpoints with little need for the Kafka connector ecosystem, so Artemis bridges and existing JMS tooling may cover the flow |
| Point-to-point work queues | Apache Artemis, because queue semantics, acknowledgments and JMS consumer behavior are its core model | Work must be distributed across many partitions with ordering per key and replay of completed work, which points back to Kafka's log model |
How Kafka and Artemis are built and what that means for operations
Kafka and Artemis solve different problems with different machinery, and the difference shows up in day-two work. This section walks through the storage model, the Kafka runtime requirements, Artemis high availability and disaster recovery, so you can match each to the team that will run it.
Partitioned log with broker-stored retention
Kafka writes each topic into partitions, and consumers track their own offsets. Records stay on the brokers for the retention period you configure, so several consumer groups can read the same events, and a new consumer can start from an earlier offset. For operations, the main work is sizing disks and partition counts, and watching retention against storage. Ask your team who owns partition layout and whether replay is a real requirement or a nice-to-have, because replay drives storage cost more than throughput does.
KRaft-only operation since 4.0
Apache Kafka 4.0 supports only KRaft mode, so ZooKeeper is no longer part of a 4.x cluster. Clusters still on ZooKeeper must migrate to KRaft first, and the upgrade notes recommend moving KRaft clusters older than 3.3.x to 3.9.x before going to 4.x. Plan this as a dated migration project, not a routine upgrade. Confirm your current version and your rolling upgrade path against the upgrade notes before scheduling any work.
Java 17 for brokers and Connect
Since Kafka 4.0, brokers, Kafka Connect and tools require Java 17, while clients and Kafka Streams applications need at least Java 11. Artemis is also a Java broker, so the JVM is not a differentiator on its own. The difference is who runs it: Kafka Connect adds another JVM service to patch and monitor, and connector plugins must be checked against that Java version. Confirm the JDK your images and hardening baseline allow before you commit to a version.
Queue semantics and non-blocking broker
Artemis is built around queues, JMS destinations and a non-blocking architecture, and it supports Jakarta Messaging 3.1 along with JMS 2.0 and 1.1. Messages are typically consumed and removed, which suits work distribution and transactional handoffs between Java applications. Teams moving from a JMS broker should test acknowledgement, selector and transaction behavior with their own clients, since those semantics differ from a partitioned log.
Journal choice and JDBC persistence
Artemis offers journal implementations for low-latency persistence, and also a JDBC option for storing messages in a relational database. The JDBC path can simplify backup and shared infrastructure for some teams, but it trades away some throughput and needs its own tuning and database operations. Decide the journal early, because changing it later means a migration. Confirm the throughput and failover behavior of each option with your own load tests, not with general claims.
High availability and mirroring for disaster recovery
Artemis provides high availability through shared storage or network replication, and asynchronous mirroring for disaster recovery. Shared storage needs a reliable storage fabric and fencing discipline, while network replication moves that responsibility into the broker pair. Asynchronous mirroring means a site failover can lose recent messages, so the recovery point objective must be written down and tested. Ask which failover mode fits your storage platform, and run a failover drill before you rely on it.
Why replay and consumer independence change the design
The core design difference is whether a message is kept as shared history or handed off once to a consumer. In Apache Kafka, records stay in partitions for the configured retention period, and each consumer group tracks its own offsets, so several independent applications can read the same history at their own pace and re-read it later. Artemis is built around addresses and queues: a message is routed to one or more queues, and consumers take messages from those queues under JMS acknowledgement semantics. Once acknowledged, the message is normally gone from that queue. The model follows the JMS contract that the Artemis site describes as full Jakarta Messaging 3.1 support, so it fits request handling and transactional work especially well.
The condition that decides this is what the business needs to do after a message is consumed. If you need an audit trail, the ability to rebuild a downstream store after a bug fix, or a new analytics consumer that must see last month's events, Kafka's retention and offset model is the natural fit, and you should check that your retention settings and topic partitioning match those replay windows. If each message must be processed exactly once by one service and then discarded, such as payment instructions or order handoffs between Java systems, Artemis's queue semantics, transactions and JMS clients usually map more directly to the application code.
Before choosing, run your own tests rather than relying on either model's general description. Replay a full retention window into a fresh consumer group and measure how long recovery takes. Then make a second consumer that fails mid-transaction on Artemis and confirm redelivery, dead-letter and duplicate-handling behavior against your JMS code. Also confirm which of your Java clients use JMS APIs, which need Kafka clients, and how long your compliance evidence must keep copies of each message.
Capability comparison: Kafka against Artemis
This table sets Apache Kafka's log-based model against Apache Artemis's multi-protocol broker across licensing, releases, protocols, security, clustering and client support. Read each row against your own integration mix: if most consumers are Java applications using JMS, the protocol and client rows matter more than throughput, and if replay across many consumers is the goal, the retention and authorization rows matter most. Items marked as items to confirm depend on your versions and configuration.
| Capability | Apache Kafka | Apache Artemis |
|---|---|---|
| License | Apache-2.0; the project itself offers no paid edition | Apache-2.0 (apache/artemis repository); became its own Apache project following an ActiveMQ PMC vote announced November 19, 2025 |
| Release cadence | Aims for three releases a year; supported lines are 4.3.1, 4.2.2 and 4.1.2 | Point releases on the Artemis site, including 2.55.0 (June 29, 2026) and 2.57.0 (September 9, 2026, a bug fix release) |
| Protocols | Kafka protocol for clients; other systems integrate through Kafka Connect or bridges | AMQP 1.0, MQTT 3.1.1, MQTT 5, STOMP, JMS 2.0 and 1.1, and Jakarta Messaging 3.1 |
| Authentication | SSL or SASL with GSSAPI (Kerberos), PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER | OIDC enhancements added in 2.55.0; confirm the exact OIDC and other provider settings for your version |
| Authorization model | StandardAuthorizer stores ACLs in the cluster metadata log; resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is true | Confirm address and queue-level role configuration in your Artemis version's documentation |
| Clustering and disaster recovery | KRaft quorum for metadata; geo-replication documented for cross-cluster mirroring | Flexible clustering, high availability via shared storage or network replication, and asynchronous mirroring for disaster recovery |
| Java requirements | Brokers, Kafka Connect and tools require Java 17 since 4.0; clients and Kafka Streams need at least Java 11 | Java-based broker; confirm the supported JDK for your release before upgrading |
| Client languages | Official clients across many languages; Java clients and Kafka Streams are the native path for Java teams | Clients in Java, JavaScript, C, C++, Python and .NET |
| Examples and tooling | Kafka Connect provides source and sink connectors managed through a REST API | More than 90 client and broker feature examples in the Artemis examples repository |
What is free and what is paid for each platform
Apache Kafka is an Apache Software Foundation project released under the Apache License 2.0, and the project itself offers no paid edition. Using the software, modifying it and running it in your own infrastructure carries no license fee from the project. The costs that remain are the people, infrastructure and any outside services you choose to buy.
- License: Apache-2.0 for the broker, Kafka Connect and tools, with no commercial tier from the Apache project.
- Supported release lines: 4.3.1 (June 25, 2026), 4.2.2 (September 29, 2026) and 4.1.2 (March 17, 2026), per the Kafka downloads page. Older versions are archived.
- Release cadence: the project aims for three releases a year, with bugfix releases only for supported lines, so upgrade planning should follow the supported lines rather than the archive.
- Commercial support: any paid support, managed service or training comes from vendors or service firms, not from the Apache project. Each one sets its own terms.
Before you sign anything, confirm with each provider which Kafka versions it supports, what its support window covers and whether its terms include upgrade help. Ask for these in writing so the quote matches your own environment.
Apache Artemis is a multi-protocol message broker licensed under Apache-2.0, and the apache/artemis repository carries the same license. Releases are distributed from the Apache Artemis website rather than GitHub, so the download source is part of your version control process. The project's history also affects which support providers and documentation you will find.
- Project origin: the ActiveMQ PMC voted to establish Apache Artemis as its own Apache project, announced on November 19, 2025.
- Recent releases: 2.56.0 was published on August 27, 2026, and 2.57.0, a bug fix release, followed on September 9, 2026, according to the Apache Artemis website.
- Release source: download binaries from the Artemis website and verify them against the project's published checksums and signatures before use.
- Commercial support: the Apache project does not sell support. Confirm which vendors offer Artemis support, their supported versions and their response terms.
Before committing, check the Artemis release notes for each version you plan to run, and confirm with any support provider whether a bug fix release such as 2.57.0 is covered by their contract.
Neither project sells a commercial support tier, so any paid support, managed hosting or training comes from separate companies. This is the main place where the cost of each platform differs in practice. The license is the same kind of free for both, but the support contract, the people you hire and the time your own staff spend are not.
- Who you pay: support vendors, managed service providers, consultants and training firms, each with its own scope.
- What recurs: annual or monthly support contracts, retainers and any upgrade work bought each year.
- What is one-time: initial deployment, migration of existing clients or topics, and integration with Java enterprise systems.
- What to ask for in a quote: the exact versions covered, support hours, upgrade assistance, security patch handling and the process for escalation.
Ask each provider to name the Kafka or Artemis versions in its written scope and to state how it will handle the next supported release. Confirm these points directly with the vendor, since the project pages do not describe commercial terms.
What drives running cost for Kafka and Artemis
This table sets out the infrastructure, skills, upgrade and support drivers behind running Apache Kafka or Apache Artemis in your own infrastructure. Read each row for what recurs and what to put in a written scope or quote, since neither project publishes a price and running cost depends on your volumes, retention and controls.
| Cost driver | Apache Kafka | Apache Artemis |
|---|---|---|
| Broker and node count | Brokers, plus a controller quorum that can be combined with brokers or run on dedicated nodes. Count depends on throughput, replication factor and fault domains. | Broker pairs or clusters for HA, using shared storage or network replication. Count depends on message rate, client connections and the redundancy you require. |
| Storage for retention | Retention is a core design input. Keeping events for replay multiplies disk per broker across replicas, so retention period and volume drive recurring storage cost. | Storage is sized for the persistence journal and queued messages. Messages usually leave the broker once consumed, so long replay windows are not the default cost driver. |
| Controller layout | KRaft controllers are a recurring node cost if run on dedicated hardware. Confirm the layout your risk team accepts before quoting node counts. | No separate controller tier is described in the supplied material. Confirm the HA topology and quorum or witness requirements for your environment. |
| Skills to run it | Staff need JVM tuning, KRaft operations, topic and partition management and security configuration (SSL or SASL, ACLs in the metadata log). | Staff need JMS and Jakarta Messaging configuration, HA and failover tuning, and address and queue design. JVM knowledge is also required because Artemis runs on Java. |
| Connector maintenance | Kafka Connect source and sink connectors are a recurring cost: each connector version, its configuration and its target system need ongoing ownership. | Integration is mostly through JMS, AMQP, MQTT and STOMP clients rather than a connector catalog. Ongoing cost sits in client libraries and protocol configuration. |
| Upgrade effort | Rolling upgrades are supported from each release in the past year to the latest version. Plan regular upgrades, and migrate any ZooKeeper cluster to KRaft before moving to 4.x. | Upgrade cadence and compatibility for your JMS clients and HA pairs need to be confirmed against the release notes for your version (for example, 2.57.0 or later). |
| Support options | The project is Apache-2.0 with no paid edition from the project itself. Support comes from a vendor, a distribution or an implementation partner under a written scope. | Apache-2.0 with no paid edition named in the supplied material. Confirm whether a commercial support provider is available for your Artemis version and region. |
Moving integrations from Artemis to Kafka or back
This sequence turns a mixed Artemis and Kafka estate into a documented migration plan, so each flow moves on evidence rather than on a single cutover date. It produces a flow inventory, a replay decision for every flow, a messaging map, parallel-run results and a per-flow cutover record.
Inventory producers, consumers and protocols
List every producer and consumer that touches Artemis, including the JMS client library and version, the destination type (queue or topic), the protocol used (JMS, AMQP 1.0, MQTT 3.1.1 or MQTT 5, or STOMP) and the message schema. Record which systems are Java enterprise applications and which are non-Java clients, because the non-Java clients use different libraries on both platforms. The step is done when every flow has one row in a shared inventory and the owning team has signed off on it.
Decide which flows need replay
For each inventoried flow, decide whether consumers need to re-read past messages, for example to rebuild a downstream store, backfill a new service or reprocess after a defect. Kafka retains records in partitioned logs for a configured period, so replay is a native pattern there, while Artemis is built around queues where a message is normally consumed once. Flows that need replay are candidates for Kafka. Flows that only need delivery to a consumer may stay on Artemis. The output is a replay column in the inventory with a named owner for each decision.
Map JMS destinations to topics or keep a bridge
Translate each JMS queue and topic into a Kafka topic with an explicit partition count, key strategy and retention setting, or mark the flow as staying on Artemis behind a bridge. Kafka does not implement JMS, so Java applications that depend on JMS APIs will need code changes or a bridge component, and you should confirm any bridge option against your own environment. Document message ordering requirements, since ordering in Kafka is guaranteed within a partition. The step is complete when every destination has a target and an ordering note.
Rebuild offset handling and idempotency
Replace JMS acknowledgment logic with consumer group offset management, deciding when offsets are committed relative to business side effects. Artemis tracks acknowledgment per message, while Kafka consumers commit a position in the log, so duplicate processing after a restart becomes a design concern. Add idempotent writes or deduplication keys in each consumer, and test redelivery with a deliberate restart. The output is a test report showing that processing outcomes match between a duplicate-delivery run and a clean run.
Carry over schemas and identity configuration
Move message schemas, field definitions and versioning rules to the Kafka side, since these transfer with the business meaning of the data. Review identity configuration concepts as well: Kafka authenticates clients with SSL or SASL, with mechanisms that include GSSAPI, PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER, and authorizes access through ACLs in KRaft clusters. Artemis security settings do not map one to one, so rebuild the access rules and confirm them with a security reviewer. The step is done when each flow has a documented principal, mechanism and ACL set.
Run both platforms in parallel
For each migrating flow, publish to both Artemis and Kafka during a validation window, and compare message counts, payload checksums and consumer outputs. Keep the old consumer as the system of record until the new consumer's results match. Record every mismatch with a cause and a fix. The output is a parallel-run log per flow that the owning team and the operations team both sign.
Cut over flow by flow
Switch one flow at a time from Artemis to Kafka, or move a flow back, using a documented rollback path for each. Stop publishing to the old destination only after the consumer has run cleanly on the new one, and keep the old destination readable until the rollback window closes. Update the inventory, monitoring and runbooks for each cut. The step is complete when every flow in the inventory has a dated cutover record and no flow depends on a retired destination.
Where Kafka and Artemis implementation projects run long
Kafka projects usually slow down in four places: security configuration, KRaft cluster layout, Connect connector governance and schema decisions. Security is optional in Kafka, so teams must decide which listeners use SSL/TLS and which SASL mechanism (GSSAPI, PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 or OAUTHBEARER) each client group will use, then set ACLs in the StandardAuthorizer. Because resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true, a missed ACL often surfaces late as a production client failure. Confirm your identity provider's support for the chosen mechanism before the build starts, and plan the cluster layout around whether controllers run combined with brokers or on dedicated nodes.
Artemis projects tend to run long in the JMS client migration, protocol mapping and clustering or replication setup. Existing Java applications built on JMS 2.0 or Jakarta Messaging 3.1 usually need dependency and connection factory changes, and any code that depends on broker-specific behavior needs review. Where AMQP 1.0, MQTT 5 or STOMP clients share queues with JMS consumers, the team must map how addresses, routing and message properties translate across protocols, and test that behavior with real clients. For high availability, decide between shared storage and network replication, and between the journal and JDBC persistence options, before load testing. Confirm the exact Artemis release you will run against the current Apache Artemis site.
Both platforms need the same things from the client team: named owners for identity, network and data decisions, a test environment that matches production topology, and an agreed schema or message contract before connectors or consumers are built. Engagements tend to run more predictably when the scope is written down, with deliverables and acceptance tests for security configuration, cluster layout and client migration. A fixed-scope engagement helps most when the client team lacks Kafka or Artemis operations experience, or when one integration phase blocks several others. DeployOpen plans and implements these systems in your own infrastructure and agrees scope and deliverables in writing before work starts, so the boundaries of the work are clear to both parties.
Questions buyers ask before choosing Kafka or Artemis
How much implementation effort does Kafka need compared with Artemis?
Kafka usually asks for more upfront design work because the team must decide on partition counts, retention periods, replication settings, consumer group layout and how Kafka Connect will move data in and out. Current Kafka 4.x releases run only in KRaft mode, so the team also chooses the controller layout and security model, including SSL or SASL and ACLs in the StandardAuthorizer. Artemis is often quicker to stand up for JMS or AMQP workloads because its queues, addresses and clustering model map closely to existing Java enterprise code. The effort rises for both when clustering, high availability, mirroring and monitoring must meet audit expectations. Ask each vendor or partner for a written list of the components, configuration decisions and test cases that the work includes.
Can our internal team run Kafka or Artemis without outside help?
Yes, many teams run both themselves, but the answer depends on existing skills and on how many environments the platform must cover. A team that already operates JVM services, Linux, TLS certificates and a monitoring stack has most of the prerequisites for either broker. Kafka needs staff who understand partitions, consumer lag, rolling upgrades and KRaft controller health, while Artemis needs staff who understand its addressing model, journal storage and cluster failover. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted platforms in the client's own infrastructure, typically under a fixed-scope engagement with ongoing support as a retainer. Teams that keep operations in-house can still use a short fixed-scope engagement for design review and hardening.
How long does a migration from Artemis to Kafka usually take?
No single duration applies, because the timeline depends on the scope of the change rather than on the platform name alone. The main drivers are the number of producers and consumers, whether JMS or AMQP clients must be rewritten to the Kafka protocol, how much message history must be replayed or kept, and how many systems depend on exact delivery semantics. Teams that run both platforms during a transition add time for dual publishing, reconciliation and rollback testing. Ask for a written phased plan that lists each consumer group, the cutover order and the acceptance tests before agreeing to a schedule. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the plan should come from the inventory of your own systems.
Can Artemis replace Kafka for event replay?
Only for some patterns. Kafka keeps records in partitioned logs for a configured retention period, and consumers can reset their offsets and read the history again, which is the core of its replay model. Artemis is built around queues, topics and addresses with JMS, AMQP, MQTT and STOMP delivery, and its journal and clustering features support durability and failover rather than long-term replay of an event log. If replay is a hard requirement for audit, analytics or rebuilding downstream state, Kafka is the closer fit. If a design only needs reliable delivery to Java consumers with occasional redelivery, Artemis may be enough. Confirm the exact retention and redelivery behavior you need against the current Artemis and Kafka documentation before you commit.
How does licensing affect support choices for Kafka and Artemis?
Both projects are Apache-2.0 licensed, so neither requires a commercial license to run, and the Kafka project itself has no paid edition. Licensing does not decide support, though. Apache Kafka is distributed by the Apache Software Foundation, while Artemis releases come from the Apache Artemis website, so support must come from an engagement you contract separately. Ask any vendor or partner which versions they support, what their support window is and whether they cover upgrades and security patches. Also confirm whether they support your chosen Kafka 4.x or Artemis 2.x release. DeployOpen supports these platforms through fixed-scope work and retainers, and the written scope should state exactly which versions and components are covered.
What should we confirm in a quote for Kafka or Artemis work?
A quote should follow from a written scope, and it should list the deliverables, environments, assumptions and exclusions before any work starts. Ask which platforms, versions and components are included, such as Kafka Connect, KRaft controllers, Artemis clustering, mirroring and monitoring. Confirm which items are one-time, including design, implementation, migration and hardening, and which recur, including upgrades, backups, patching and support retainers. Ask how the scope changes if you add topics, consumers or clusters, and who runs acceptance testing. Also ask what the client team must provide, such as hosts, certificates, identity integration and access for the work. DeployOpen does not publish a price list, so the quote is the place to compare costs.
How DeployOpen helps choose and implement either platform
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens and documents self-hosted open-source platforms inside the client's own infrastructure, whether that is a cloud account, a data center or an air-gapped network. We do not recommend Apache Kafka or Apache Artemis by default. The right choice depends on your Java estate, your replay requirements and which protocols your producers and consumers already speak, so we start by mapping those against the workload rather than against a preferred product. Most engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins, and a quote follows from that written scope.
In a Kafka or Artemis project, the decisions that matter most are concrete: how partitions and retention are sized, whether Kafka Connect or Artemis's JMS interfaces carry the Java enterprise integrations, how clients authenticate, and how the broker is backed up, upgraded and monitored over its life. We can design those pieces, build the connectors or client configuration, harden listeners and authorization, and write the runbooks your operations team will use. Where a platform needs ongoing attention, such as upgrades or continuous testing, that work can be covered by a retainer. Scope and ownership of each control are recorded in the agreement so both sides know who operates what after go-live.
Ask any implementation partner, including DeployOpen, to show how the scope will be documented and what evidence each control will produce. For a messaging platform that means configuration baselines, access reviews and tested recovery steps. DeployOpen prepares these systems and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and independent auditors and certification bodies make those determinations. Before you request a quote, confirm the version and support window you intend to run against the vendor's own documentation, for example the Apache Kafka downloads page, so the written scope reflects the release you will actually operate.
