I have a basic Ignite persistence setup working. For now, it's a single node running in server mode, from which I connect two clients. When I insert data via SQL from one of these clients ("Client 1" below), I can SELECT it again with SQL and get results back. From "Client 2" below, when I try to grab the cache which ought to have been created to represent this table, it is null.
The server runs the apacheignite image using the following Dockerfile:
server/Dockerfile:
FROM apacheignite/ignite
# for jdbc connection
EXPOSE 10800
EXPOSE 47100-47109
EXPOSE 47500-47509
# for rest api
EXPOSE 8080
WORKDIR /app
COPY ./config /app/config
RUN mv /opt/ignite/apache-ignite/libs/optional/ignite-aws /opt/ignite/apache-ignite/libs/
RUN mv /opt/ignite/apache-ignite/libs/optional/ignite-rest-http /opt/ignite/apache-ignite/libs/
CMD /opt/ignite/apache-ignite/bin/ignite.sh /app/config/ignite-config.xml -v
The relevant parts of the ignite-config.xml referenced here is as follows:
/app/config/ignite-config.xml
<bean class="org.apache.ignite.configuration.IgniteConfiguration">
<property name="dataStorageConfiguration">
<bean class="org.apache.ignite.configuration.DataStorageConfiguration">
<property name="defaultDataRegionConfiguration">
<bean class="org.apache.ignite.configuration.DataRegionConfiguration">
<property name="persistenceEnabled" value="true"/>
</bean>
</property>
</bean>
</property>
<property name="discoverySpi">
<bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
<property name="ipFinder">
<bean class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
<property name="addresses">
<list>
<value>127.0.0.1:47500..47509</value>
</list>
</property>
</bean>
</property>
</bean>
</property>
</bean>
I've also made sure to activate the cluster on the Server container using since Persistence sets the cluster to inactive by default.
/opt/ignite/apache-ignite/bin/control.sh --activate
Client 1
Client 1 connects over the Thin JDBC driver and does some CREATE TABLEs and INSERTs. When I later SELECT in something like DBeaver, I can see this data.
This client also runs in docker, alongside the other in Compose. All it really does is call the following in a loop, where $file is a SQL file containing CREATE TABLE, INSERTs, etc.
/opt/ignite/apache-ignite/bin/sqlline.sh -u jdbc:ignite:thin://server:10800 -f $file;
One such SQL file looks like:
DROP TABLE IF EXISTS attributes;
DROP INDEX IF EXISTS idx_attributes_token;
CREATE TABLE attributes (
token VARCHAR,
attributeId LONG,
name VARCHAR,
PRIMARY KEY(token, attributeId)
) WITH "affinityKey=token";
CREATE INDEX idx_attributes_token ON attributes (token);
INSERT INTO attributes (token, attributeId, name) VALUES ('abc123', 123, 'some name');
Client 2
Client 2 connects to Ignite more or less as follows:
IgniteConfiguration igniteConfiguration = new IgniteConfiguration();
TcpDiscoverySpi discoverySpi = new TcpDiscoverySpi();
TcpDiscoveryMulticastIpFinder ipFinder = new TcpDiscoveryMulticastIpFinder();
ipFinder.setAddresses(igniteConfig.getAddresses()); // will be "localhost:10800" -- I map 10800:10800 when the "Server" container runs
discoverySpi.setIpFinder(ipFinder);
igniteConfiguration.setDiscoverySpi(discoverySpi);
Ignite ignite = Ignition.start(igniteConfiguration);
IgniteCache<Object, String> attributesCache = ignite.cache("SQL_PUBLIC_ATTRIBUTES"); // null
// if i use ignite.getOrCreateCache("SQL_PUBLIC_ATTRIBUTES") instead then of course it's a cache of size 0.
Ultimately, I want to be able to grab hold of this cache and use the StreamVisitor described in the Ignite docs to perform operations on each. That would allegedly look like:
...
IgniteDataStreamer<Object, AttributeWithGroup> attributeStreamer = ignite.dataStreamer(attributesCache.getName());
attributeStreamer.receiver(StreamVisitor.from((cache, entity) -> {
Object key = entity.getKey();
Attribute attribute = entity.getValue();
// do some stuff
}));
...but the lambda never runs, because the cache is null.
Why is there this disconnect between what I can see in SQL and what I can see in the Cache?
