[jira] [Created] (IGNITE-9855) Curious deadlock on shutdown when being polled over Jetty/REST

2018-10-11 Thread Paul Anderson (JIRA) 
Paul Anderson created IGNITE-9855:
-

 Summary: Curious deadlock on shutdown when being polled over 
Jetty/REST
 Key: IGNITE-9855
 URL: https://issues.apache.org/jira/browse/IGNITE-9855
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.6
Reporter: Paul Anderson


have a look at this curious stack trace 

 

Attaching to process ID 2375242, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.71-b15
Deadlock Detection:

No deadlocks found.

Thread 2391956: (state = BLOCKED)
 - sun.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame; information may 
be imprecise)
 - java.util.concurrent.locks.LockSupport.park(java.lang.Object) @bci=14, 
line=175 (Compiled frame)
 - 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await() 
@bci=42, line=2039 (Compiled frame)
 - java.util.concurrent.LinkedBlockingQueue.take() @bci=29, line=442 (Compiled 
frame)
 - java.util.concurrent.ThreadPoolExecutor.getTask() @bci=149, line=1067 
(Interpreted frame)
 - 
java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker)
 @bci=26, line=1127 (Interpreted frame)
 - java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=5, line=617 
(Interpreted frame)
 - java.lang.Thread.run() @bci=11, line=745 (Interpreted frame)


Thread 2391794: (state = BLOCKED)
 - sun.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame; information may 
be imprecise)
 - java.util.concurrent.locks.LockSupport.park(java.lang.Object) @bci=14, 
line=175 (Compiled frame)
 - 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await() 
@bci=42, line=2039 (Compiled frame)
 - java.util.concurrent.LinkedBlockingQueue.take() @bci=29, line=442 (Compiled 
frame)
 - java.util.concurrent.ThreadPoolExecutor.getTask() @bci=149, line=1067 
(Interpreted frame)
 - 
java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker)
 @bci=26, line=1127 (Interpreted frame)
 - java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=5, line=617 
(Interpreted frame)
 - java.lang.Thread.run() @bci=11, line=745 (Interpreted frame)


Thread 2391563: (state = BLOCKED)
 - sun.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame; information may 
be imprecise)
 - java.util.concurrent.locks.LockSupport.park(java.lang.Object) @bci=14, 
line=175 (Compiled frame)
 - 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await() 
@bci=42, line=2039 (Compiled frame)
 - java.util.concurrent.LinkedBlockingQueue.take() @bci=29, line=442 (Compiled 
frame)
 - java.util.concurrent.ThreadPoolExecutor.getTask() @bci=149, line=1067 
(Interpreted frame)
 - 
java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker)
 @bci=26, line=1127 (Interpreted frame)
 - java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=5, line=617 
(Interpreted frame)
 - java.lang.Thread.run() @bci=11, line=745 (Interpreted frame)


Thread 2391461: (state = BLOCKED)
 - sun.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame; information may 
be imprecise)
 - java.util.concurrent.locks.LockSupport.park(java.lang.Object) @bci=14, 
line=175 (Compiled frame)
 - 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await() 
@bci=42, line=2039 (Compiled frame)
 - java.util.concurrent.LinkedBlockingQueue.take() @bci=29, line=442 (Compiled 
frame)
 - java.util.concurrent.ThreadPoolExecutor.getTask() @bci=149, line=1067 
(Interpreted frame)
 - 
java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker)
 @bci=26, line=1127 (Interpreted frame)
 - java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=5, line=617 
(Interpreted frame)
 - java.lang.Thread.run() @bci=11, line=745 (Interpreted frame)


Thread 2391460: (state = BLOCKED)
 - sun.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame; information may 
be imprecise)
 - java.util.concurrent.locks.LockSupport.park(java.lang.Object) @bci=14, 
line=175 (Compiled frame)
 - 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await() 
@bci=42, line=2039 (Compiled frame)
 - java.util.concurrent.LinkedBlockingQueue.take() @bci=29, line=442 (Compiled 
frame)
 - java.util.concurrent.ThreadPoolExecutor.getTask() @bci=149, line=1067 
(Interpreted frame)
 - 
java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker)
 @bci=26, line=1127 (Interpreted frame)
 - java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=5, line=617 
(Interpreted frame)
 - java.lang.Thread.run() @bci=11, line=745 (Interpreted frame)


Thread 2383112: (state = BLOCKED)
 - sun.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame; information may 
be imprecise)
 - java.util.concurrent.locks.LockSupport.park(java.lang.Object) @bci=14,

[jira] [Created] (IGNITE-9298) control.sh does not support SSL (org.apache.ignite.internal.commandline.CommandHandler)

2018-08-16 Thread Paul Anderson (JIRA) 
Paul Anderson created IGNITE-9298:
-

 Summary: control.sh does not support SSL 
(org.apache.ignite.internal.commandline.CommandHandler)
 Key: IGNITE-9298
 URL: https://issues.apache.org/jira/browse/IGNITE-9298
 Project: Ignite
  Issue Type: Bug
  Components: clients
Affects Versions: 2.6
Reporter: Paul Anderson
 Attachments: Arguments.patch, CommandHandler.patch

We required SSL on the connector port and to use control.sh to work with the 
baseline configuration.

This morning I added support, see attached patches against 2.6.0 for 

org/apache/ignite/internal/commandline/CommandHandler.java

org/apache/ignite/internal/commandline/Arguments.java

No tests, no docs.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8439) IGNITE_JETTY_HOST doesn't work (never has probably)

2018-05-04 Thread Paul Anderson (JIRA) 
Paul Anderson created IGNITE-8439:
-

 Summary: IGNITE_JETTY_HOST doesn't work (never has probably)
 Key: IGNITE-8439
 URL: https://issues.apache.org/jira/browse/IGNITE-8439
 Project: Ignite
  Issue Type: Bug
  Components: rest
Affects Versions: 2.4
Reporter: Paul Anderson


GridJettyRestProtocol.java

 

 public void start(GridRestProtocolHandler hnd)

...

System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress())

...

should be

 if(System.getProperty(IGNITE_JETTY_HOST)==null) 
System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress());



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7457) Authorization happens on the Client not Server

2018-01-17 Thread Paul Anderson (JIRA) 
Paul Anderson created IGNITE-7457:
-

 Summary: Authorization happens on the Client not Server
 Key: IGNITE-7457
 URL: https://issues.apache.org/jira/browse/IGNITE-7457
 Project: Ignite
  Issue Type: Bug
  Components: cache, clients, general
Affects Versions: 2.3
 Environment: 2.3.0 Gentoo Linux J1.8
Reporter: Paul Anderson


Whilst writing an Authentication/Authorization plugin I notice that 
authorisation takes place on the client rather than on the server (new node 
authentication takes part on the server) this seems a little insecure as the 
client can easily deploy with a modified (or without the) plugin.

Just an observation...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)