Let me have a summarize here. Working with
| IgniteDataFrameSettings.OPTION_CONFIG_FILE(), configPath |
seems to work fine.
But when I'm using the JDBC thin client connection, (like connecting to a
database through JDBC Driver) it was giving me the error:
*java.sql.SQLException: No PRIMARY KEY
Columns information is read by thin-client only after the first data
request, so you need to read at least one row to get columns.
вт, 3 нояб. 2020 г. в 09:31, Ilya Kazakov :
> Hello, Shravya! It is very interesting! I am trying to reproduce your
> case, and what I see. I can see column names in
Hello, Shravya! It is very interesting! I am trying to reproduce your case,
and what I see. I can see column names in the thin client only after query
execution.
For example:
ClientConfiguration clientConfig = new
ClientConfiguration().setAddresses("127.0.0.1");
try(IgniteClient thinClient =
Hi Ilya,
My bad I forgot to push the changes. Now I just pushed the changes so you
can find the required details.
BR,
Ashish
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Please find details below
Java - 1.8
Hikari - 3.4.1
Ignite - 2.6.0
SSL Enabled - false
Thanks,
Sanjaya
On Mon, Nov 2, 2020 at 8:11 PM Vladimir Pligin wrote:
> Hi,
>
> What java version do you use? What about Hikari & Ignite versions? Do you
> have SSL enabled?
>
>
>
> --
> Sent from:
Hi,
For Ignite thick client, the below sql query is throwing CacheException with
the following code:
public class ClientNode {
public static void main(String[] args) {
IgniteConfiguration igniteCfg = new IgniteConfiguration();
igniteCfg.setClientMode(true);
Ignite
Hello, Ashish! But I can not find poc.ignite.service.ComputeService class
by your link. Maybe you sent the wrong link?
Check, please.
Ilya Kazakov
вт, 3 нояб. 2020 г. в 12:11, ashishb888 :
> Awaiting response. If you anything else let me know
>
> BR,
> Ashish
>
>
>
> --
> Sent from:
Hi,
For Ignite thick client, the column names for a given sql query are coming up
as expected with the following code:
public class ClientNode {
public static void main(String[] args) {
IgniteConfiguration igniteCfg = new IgniteConfiguration();
igniteCfg.setClientMode(true);
Awaiting response. If you anything else let me know
BR,
Ashish
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Hi,
We saw all ignite nodes crash today morning. Below are the error logs?
why would "Failed to Resolve Node Topology" occur?
what would cause this?
If there is a network disturbance, should I not get some sort of segmentation
error?
Hi
I have a large SQL table (12 million records) in cacheMode partitioned.
This table is distributed over two server nodes
-1-
When running a large SELECT from a thick client node, could data be fetched
from the backup instead of primary partitions?
Below is the configuration.
/>
Thank you for response. If I understand correctly, so thick client
connectivity time is not depending on # of server nodes, it all depends on
PME length ? Can you please elaborate or point me to the resources where I
can understand PME length ? I got few links on how PME works. But sorry I
did not
Thanks, please do keep us posted - perhaps with a ticket number or something
we can track as this is currently a blocker for putting ignite into
production.
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Hello!
What I have noticed in your logs is a huge number of network errors:
Suppressed: class org.apache.ignite.IgniteCheckedException: Failed
to connect to address [addr=
vrnv02ax04705.INT.CARLSONWAGONLIT.COM/10.212.120.67:51605, err=Failed to
read remote n
ode recovery handshake
P.S. here's a screenshot of where this is coming from:
Note, some binary meta data seems to be about remote filters and
transformers that have been issued by other client apps connected to the
cluster (we do not want this stuff propagated to this client app either).
The rest of the binary meta
Hi,
Long JVM pauses can lead to different problems, but in your case, I see
some network problems that lead to a segmentation of some nodes:
Connection to Zookeeper server is lost, local node SEGMENTED.
What you can do to avoid current problem:
1)You should find out the reason for the pause.
Hi,
What java version do you use? What about Hikari & Ignite versions? Do you
have SSL enabled?
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Hello,
You can use events:
https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/events/CacheRebalancingEvent.html
But in this case, you should wait until the rebalancing of all caches is
completed.
Also you can use the web console tool:
Hi,
Here is the client config:
">
">
"
Hello!
I don't think this is the issue of configuration, rather than how many
nodes you are having and the length of your transactions/operations.
It's all about PME length.
Regards,
--
Ilya Kasnacheev
пн, 2 нояб. 2020 г. в 16:05, Hemambara :
> Thank you Stephen and Ilya for your response.
Hello!
Okay, that's not very cool. I hope to get some response from development
side at this point.
Sans reaction, I will file a ticket.
Regards,
--
Ilya Kasnacheev
пн, 2 нояб. 2020 г. в 15:03, ssansoy :
> Apologies I may have spoken to soon (I was looking at the wrong process).
>
> It
Thank you Stephen and Ilya for your response.
Please find my server and client config and let me know if I a missing
anything which is causing these delays. We have 8 jvm server nodes running
on Ignite 2.8.0 with 4gig each and each node is on separate host. We have 60
client nodes (Ignite 2.8.0)
IgniteAtomicLong shows poor results in case of non zero backups.
But IgniteAtomicSequence incremented 1M by ~0.4 second in the attached
example.
ср, 28 окт. 2020 г. в 13:45, narges saleh :
> Thanks Pavel for the replies.
>
> I did a quick/basic benchmark of IgniteAtomicLong, and
Hello!
You may actually use our data streamer (with allowOverwrite false).
Once you call flush() on it and it returns, you should be confident that
all 10,000 entries are readable from cache. Of course it has to be 1 cache.
Regards,
--
Ilya Kasnacheev
вт, 27 окт. 2020 г. в 13:18, ssansoy :
Apologies I may have spoken to soon (I was looking at the wrong process).
It looks like we can't turn EVT_NODE_METRICS_UPDATED off as it is designated
as an internal event GridEventStorageManager.disableEvents line 441 (ignite
2.8.1), this checks to see if the event that is being disabled is
That's great! seems to eliminate a lot of the traffic. Are there any other
optimizations like this you know of that we can make to reduce this any
further?
We also have the issue documented in this thread:
Hello!
No, it is not supposed to reduce the time taken. Instead, it is solving the
problem that client may be behind NAT and not reachable from outside. Or
server nodes may be inside K8S with similar results.
Thick client will still take time to connect since it triggers PME. Clients
were never
The one-way-thick-client is designed to solve network topology issues (where
host resolution works one way but not the other). There are a lot of
improvements in 2.9 so it’s certainly worth trying.
We’d need to know more about your topology — number of nodes, sizes, etc — to
get to the bottom
Hi All,
we are trying to use HIkari connection pooling with ignite JdbcThinDriver.
we are facing issue as
Any idea what is the supported connection pooling mechanism work with
IgniteThinDriver
ERROR LOG
==
WARN com.zaxxer.hikari.pool.ProxyConnection.157 sm-event-consumer
29 matches
Mail list logo
