[jira] [Created] (IGNITE-11183) Web console: Unexpected java.net.SocketTimeoutException: connect timed out
Andrey Novikov created IGNITE-11183: --- Summary: Web console: Unexpected java.net.SocketTimeoutException: connect timed out Key: IGNITE-11183 URL: https://issues.apache.org/jira/browse/IGNITE-11183 Project: Ignite Issue Type: Task Components: wizards Affects Versions: 1.9 Reporter: Andrey Novikov Fix For: 2.8 While running the agent 1.9 jar, connection timed out error occurs. Caused by: java.net.SocketTimeoutException: connect timed out at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method) at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source) at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source) at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source) at java.net.AbstractPlainSocketImpl.connect(Unknown Source) at java.net.PlainSocketImpl.connect(Unknown Source) at java.net.SocksSocketImpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at sun.security.ssl.SSLSocketImpl.connect(Unknown Source) at sun.net.NetworkClient.doConnect(Unknown Source) at sun.net.www.http.HttpClient.openServer(Unknown Source) at sun.net.www.http.HttpClient.openServer(Unknown Source) at sun.net.www.protocol.https.HttpsClient.(Unknown Source) at sun.net.www.protocol.https.HttpsClient.New(Unknown Source) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getHeaderFields(Unknown Source) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getHeaderFields(Unknown Source) at io.socket.engineio.client.transports.PollingXHR$Request$1.run(PollingXHR.java:211) ... 1 more [11:33:04,423][ERROR][EventThread][AgentLauncher] Connection closed: transport error. [11:33:05,523][INFO ][EventThread][AgentLauncher] Connecting to: https://web-console [11:33:23,177][INFO ][EventThread][AgentLauncher] Connection established. [11:33:27,251][INFO ][EventThread][AgentLauncher] Authentication success. [11:34:29,170][ERROR][EventThread][AgentLauncher] Failed to establish connection to server, due to proxy requires authentication. In the same time, https://web-console can be reached via curl providing the proxy configuration -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11182) Web console: Actualize grid configurator
Vasiliy Sisko created IGNITE-11182: -- Summary: Web console: Actualize grid configurator Key: IGNITE-11182 URL: https://issues.apache.org/jira/browse/IGNITE-11182 Project: Ignite Issue Type: Improvement Reporter: Vasiliy Sisko Assignee: Vasiliy Sisko WebConsoleConfigurationSelfTest has found the next difference: Result for class: org.apache.ignite.hadoop.fs.CachingHadoopFileSystemFactory Missed userNameMapper Result for class: org.apache.ignite.ssl.SslContextFactory Missed cipherSuites protocols Result for class: org.apache.ignite.configuration.CacheConfiguration Missed cacheWriterFactory expiryPolicyFactory types storeConcurrentLoadAllThreshold sqlIndexMaxInlineSize sqlOnheapCacheEnabled interceptor invalidate diskPageCompression storeByValue sqlOnheapCacheMaxSize eagerTtl evictionPolicyFactory encryptionEnabled eventsDisabled cacheLoaderFactory keyConfiguration cacheStoreSessionListenerFactories diskPageCompressionLevel maxQueryIteratorsCount affinity Deprecated rebalanceThreadPoolSize transactionManagerLookupClassName Removed isInvalidate -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Best Effort Affinity for thin clients
Igor, I have a feeling that we should omit Cache Group stuff from the protocol. It is a rare use case and even then dealing with them on client barely saves some memory. We can keep it simple and have partition map per cacheId. Thoughts? On Fri, Feb 1, 2019 at 6:49 PM Igor Sapego wrote: > Guys, I've updated the proposal once again [1], so please, > take a look and let me know what you think. > > [1] - > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients > > Best Regards, > Igor > > > On Thu, Jan 17, 2019 at 1:05 PM Igor Sapego wrote: > > > Yeah, I'll add it. > > > > Best Regards, > > Igor > > > > > > On Wed, Jan 16, 2019 at 11:08 PM Pavel Tupitsyn > > wrote: > > > >> > to every server > >> I did not think of this issue. Now I agree with your approach. > >> Can you please add an explanation of this to the IEP? > >> > >> Thanks! > >> > >> On Wed, Jan 16, 2019 at 2:53 PM Igor Sapego wrote: > >> > >> > Pavel, > >> > > >> > Yeah, it makes sense, but to me it seems that this approach can lead > >> > to more complicated client logic, as it will require to make > additional > >> > call > >> > to every server, that reports affinity topology change. > >> > > >> > Guys, WDYT? > >> > > >> > Best Regards, > >> > Igor > >> > > >> > > >> > On Tue, Jan 15, 2019 at 10:59 PM Pavel Tupitsyn > > >> > wrote: > >> > > >> > > Igor, > >> > > > >> > > > It is proposed to add flag to every response, that shows whether > >> the > >> > > Affinity Topology Version of the cluster has changed since the last > >> > request > >> > > from the client. > >> > > I propose to keep this flag. So no need for periodic checks. Makes > >> sense? > >> > > > >> > > On Tue, Jan 15, 2019 at 4:45 PM Igor Sapego > >> wrote: > >> > > > >> > > > Pavel, > >> > > > > >> > > > This will require from client to send this new request > periodically, > >> > I'm > >> > > > not > >> > > > sure this will make clients simpler. Anyway, let's discuss it. > >> > > > > >> > > > Vladimir, > >> > > > > >> > > > With current proposal, we will have affinity info in message > header. > >> > > > > >> > > > Best Regards, > >> > > > Igor > >> > > > > >> > > > > >> > > > On Tue, Jan 15, 2019 at 11:01 AM Vladimir Ozerov < > >> voze...@gridgain.com > >> > > > >> > > > wrote: > >> > > > > >> > > > > Igor, > >> > > > > > >> > > > > I think that "Cache Partitions Request" should contain affinity > >> > > topology > >> > > > > version. Otherwise we do not know what distribution is returned > - > >> the > >> > > one > >> > > > > we expected, or some newer one. The latter may happen in case > >> > topology > >> > > > > changed or late affinity assignment happened between server > >> response > >> > > and > >> > > > > subsequent client partitions request. > >> > > > > > >> > > > > Vladimir. > >> > > > > > >> > > > > On Mon, Jan 14, 2019 at 6:08 PM Igor Sapego > > >> > > wrote: > >> > > > > > >> > > > > > Hello guys, > >> > > > > > > >> > > > > > I've updated IEP page [1] describing proposed solution in more > >> > > details > >> > > > > and > >> > > > > > proposing some changes for a protocol. > >> > > > > > > >> > > > > > Please, take a look and let me know what you think. > >> > > > > > > >> > > > > > [1] - > >> > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients > >> > > > > > > >> > > > > > Best Regards, > >> > > > > > Igor > >> > > > > > > >> > > > > > > >> > > > > > On Tue, Jun 19, 2018 at 11:54 AM Vladimir Ozerov < > >> > > voze...@gridgain.com > >> > > > > > >> > > > > > wrote: > >> > > > > > > >> > > > > > > Denis, > >> > > > > > > > >> > > > > > > Yes, in principle we can extend it. We are going to > implement > >> it > >> > in > >> > > > > > > subsequent phases of this IEP. > >> > > > > > > > >> > > > > > > On Tue, Jun 19, 2018 at 4:30 AM, Dmitriy Setrakyan < > >> > > > > > dsetrak...@apache.org> > >> > > > > > > wrote: > >> > > > > > > > >> > > > > > > > On Mon, Jun 18, 2018 at 11:07 AM, Denis Magda < > >> > dma...@apache.org > >> > > > > >> > > > > > wrote: > >> > > > > > > > > >> > > > > > > > > Folks, > >> > > > > > > > > > >> > > > > > > > > Feel that this functionality can be extended to the > >> automatic > >> > > > > > > reconnect, > >> > > > > > > > > can't it? Presently we require to provide a static list > of > >> > IPs > >> > > to > >> > > > > be > >> > > > > > > used > >> > > > > > > > > at a reconnect time. By having a partition map of all > the > >> > > nodes, > >> > > > > the > >> > > > > > > thin > >> > > > > > > > > client should be able to automate this piece. > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > Not sure if static IP list can be avoided. What Igor is > >> > > suggesting > >> > > > is > >> > > > > > > that > >> > > > > > > > we try to pick the best node out of the static IP list. > >> > > > > > > > > >> > > > > > > > D. > >> > > > > > > > > >> > > > > > > > >
[jira] [Created] (IGNITE-11181) [TC Bot] Avoid notifications about too old failures
Dmitriy Pavlov created IGNITE-11181: --- Summary: [TC Bot] Avoid notifications about too old failures Key: IGNITE-11181 URL: https://issues.apache.org/jira/browse/IGNITE-11181 Project: Ignite Issue Type: Task Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov Avoid emailing about failures older than some predefined limit -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [MTCGA]: new failures in builds [2818504] needs to be handled
Please ignore. It looks like TC Bot is complaining about too old failure. вс, 3 февр. 2019 г. в 03:42, : > Hi Igniters, > > I've detected some new issue on TeamCity to be handled. You are more than > welcomed to help. > > If your changes can lead to this failure(s): We're grateful that you were > a volunteer to make the contribution to this project, but things change and > you may no longer be able to finalize your contribution. > Could you respond to this email and indicate if you wish to continue and > fix test failures or step down and some committer may revert you commit. > > *New stable failure of a flaky test in master > IgniteClusterActivateDeactivateTestWithPersistenceAndMemoryReuse.testActivateCachesRestore_SingleNode_WithNewCaches > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-8490805128277139144&branch=%3Cdefault%3E&tab=testDetails > No changes in the build > > - Here's a reminder of what contributors were agreed to do > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute > - Should you have any questions please contact > dev@ignite.apache.org > > Best Regards, > Apache Ignite TeamCity Bot > https://github.com/apache/ignite-teamcity-bot > Notification generated at 03:41:57 03-02-2019 >
[jira] [Created] (IGNITE-11180) SQL: give more sensible names to reducer classes
Vladimir Ozerov created IGNITE-11180: Summary: SQL: give more sensible names to reducer classes Key: IGNITE-11180 URL: https://issues.apache.org/jira/browse/IGNITE-11180 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.8 # Rename classes in accordance to map/reduce approach to simplify further development # Remove dead code in reducer logic -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11179) One of two nodes fail by handler with message - threadName=ttl-cleanup-worker, blockedFor=16s
ARomantsov created IGNITE-11179: --- Summary: One of two nodes fail by handler with message - threadName=ttl-cleanup-worker, blockedFor=16s Key: IGNITE-11179 URL: https://issues.apache.org/jira/browse/IGNITE-11179 Project: Ignite Issue Type: Bug Reporter: ARomantsov Start two nodes, one of them drop after Start caches in recovery mode -- This message was sent by Atlassian JIRA (v7.6.3#76005)
