[JBoss JIRA] (JGRP-2275) ASYM_ENCRYPT: encrypt join response
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2275?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2275.
----------------------------
Resolution: Done
> ASYM_ENCRYPT: encrypt join response
> -----------------------------------
>
> Key: JGRP-2275
> URL: https://issues.jboss.org/browse/JGRP-2275
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.12
>
>
> In {{ASYM_ENCRYPT}}, when a new member joins, it sends a JOIN-REQ to the coordinator (unencrypted, as it does not yet have the secret key).
> The coordinator skips decryption, creates a JOIN-RSP, and sends it to the joiner *unencrypted*. The reason is that the joiner doesn't yet have the secret key, so it couldn't possibly decrypt the JOIN-RSP and install the view.
> (This is btw not a security issue as subsequent messages *are* encrypted and a rogue member would not be able to decrypt them. However, a rogue member would be able to join the cluster.
> To prevent this, the JOIN-RSP sent by the coordinator to the joiner will be encrypted. The joiner will not be able to decrypt it and simply drops it, but it also asks the keyserver (coord) for the secret key. Once the secret key has been received, the (retransmitted) JOIN-RSP will be received, decrypted with the received secret key and the view can be installed.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (SWSQE-288) Kiali - Istio Checker to 0.8.0
by Sunil kondkar (JIRA)
[ https://issues.jboss.org/browse/SWSQE-288?page=com.atlassian.jira.plugin.... ]
Sunil kondkar reassigned SWSQE-288:
-----------------------------------
Assignee: Sunil kondkar (was: Michael Foley)
> Kiali - Istio Checker to 0.8.0
> ------------------------------
>
> Key: SWSQE-288
> URL: https://issues.jboss.org/browse/SWSQE-288
> Project: Kiali QE
> Issue Type: Sub-task
> Reporter: Hayk Hovsepyan
> Assignee: Sunil kondkar
>
> We have a job http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Kiali-Istio-Checker
> which checks Istio installation on OC. It works with 0.7.1 Istio.
> Main jenkins pipeline is switched to Istio 0.8.0 already.
> TODO
> Update this job and the script to support Istio 0.8.0 version pods which are:
> grafana-cd99bf478-2k9zj 1/1 Running 0 19m
> istio-citadel-ff5696f6f-6m8rv 1/1 Running 0 19m
> istio-cleanup-old-ca-qmd7k 0/1 Completed 0 19m
> istio-egressgateway-58d98d898c-4qhx9 0/1 CrashLoopBackOff 7 19m
> istio-ingressgateway-6bc7c7c4bc-867sz 0/1 CrashLoopBackOff 7 19m
> istio-mixer-post-install-kjhhk 0/1 Completed 0 19m
> istio-pilot-6c5c6b586c-gq6gt 2/2 Running 0 19m
> istio-policy-5c7fbb4b9f-j2jjd 2/2 Running 0 19m
> istio-sidecar-injector-dbd67c88d-ffkgm 1/1 Running 0 19m
> istio-statsd-prom-bridge-6dbb7dcc7f-fcl8f 1/1 Running 0 19m
> istio-telemetry-54b5bf4847-5wq78 2/2 Running 0 19m
> istio-tracing-67dbb5b89f-l52vk 1/1 Running 0 19m
> prometheus-586d95b8d9-dw9xl 1/1 Running 0 19m
> servicegraph-6d86dfc6cb-25qtp 1/1 Running 1 19m
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10542) Log thread information of uncompleted EJB timer task
by Chao Wang (JIRA)
Chao Wang created WFLY-10542:
--------------------------------
Summary: Log thread information of uncompleted EJB timer task
Key: WFLY-10542
URL: https://issues.jboss.org/browse/WFLY-10542
Project: WildFly
Issue Type: Feature Request
Components: EJB
Reporter: Chao Wang
{quote}WFLYEJB0043: A previous execution of timer [id=f3b0dfdb-1e94-46be-9964-69ff376fa6c0 timedObjectId=prbz-overview.prbz-overview.Aider auto-timer?:true persistent?:true timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@2f5b46cf initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Thu May 31 00:00:00 SGT 2018 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Thu May 31 00:00:00 SGT 2018.{quote}
Warning message {{WFLYEJB0043}} indicates that the recurring timer is running longer than the interval, new timer is postponed. Because one App timer task worker thread is stuck there due to network connection failure.
If the message logs more information about running threads of current timer task beyond timer id, it would be helpful to know which thread block the timer task and to allow forcibly interrupt it which is running longer than interval.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (DROOLS-2627) Concurrent spreadsheet table validation doesn't work properly
by Toshiya Kobayashi (JIRA)
Toshiya Kobayashi created DROOLS-2627:
-----------------------------------------
Summary: Concurrent spreadsheet table validation doesn't work properly
Key: DROOLS-2627
URL: https://issues.jboss.org/browse/DROOLS-2627
Project: Drools
Issue Type: Bug
Components: build
Affects Versions: 7.6.0.Final
Reporter: Toshiya Kobayashi
Assignee: Toni Rikkola
Assume this scenarios
# A
## Create a project (say, 'proj1') and upload a spreadsheet (8000rows-spreadsheet.xls)
## Login as user1 with browser1
## Login as user2 with browser2
## user1 validates the spreadsheet (8000rows-spreadsheet.xls) and user2 validates the same spreadsheet (8000rows-spreadsheet.xls)
## empty-validation-error.png reproduced
# B
## Upload another spreadsheet (8000rows-spreadsheet2.xls) to the same project 'proj1'
## Login as user1 with browser1
## Login as user2 with browser2
## user1 validates the first spreadsheet (8000rows-spreadsheet.xls) and user2 validates the second spreadsheet (8000rows-spreadsheet2.xls)
## empty-validation-error.png reproduced
# C
## Upload another spreadsheet (8000rows-spreadsheet3.xls) to another project (say, 'proj2')
## Login as user1 with browser1
## Login as user2 with browser2
## user1 validates the first spreadsheet (8000rows-spreadsheet.xls) in 'proj1' and user2 validates the third spreadsheet (8000rows-spreadsheet3.xls) in 'proj2'
## *Doesn't reproduce the empty-validation-error.png*
So, I guess we need to limit to only one validation per project (= GAV) at the same time. It should be limited at backend service.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (SWSQE-288) Kiali - Istio Checker to 0.8.0
by Hayk Hovsepyan (JIRA)
Hayk Hovsepyan created SWSQE-288:
------------------------------------
Summary: Kiali - Istio Checker to 0.8.0
Key: SWSQE-288
URL: https://issues.jboss.org/browse/SWSQE-288
Project: Kiali QE
Issue Type: Sub-task
Reporter: Hayk Hovsepyan
Assignee: Michael Foley
We have a job http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Kiali-Istio-Checker
which checks Istio installation on OC. It works with 0.7.1 Istio.
Main jenkins pipeline is switched to Istio 0.8.0 already.
TODO
Update this job and the script to support Istio 0.8.0 version pods which are:
grafana-cd99bf478-2k9zj 1/1 Running 0 19m
istio-citadel-ff5696f6f-6m8rv 1/1 Running 0 19m
istio-cleanup-old-ca-qmd7k 0/1 Completed 0 19m
istio-egressgateway-58d98d898c-4qhx9 0/1 CrashLoopBackOff 7 19m
istio-ingressgateway-6bc7c7c4bc-867sz 0/1 CrashLoopBackOff 7 19m
istio-mixer-post-install-kjhhk 0/1 Completed 0 19m
istio-pilot-6c5c6b586c-gq6gt 2/2 Running 0 19m
istio-policy-5c7fbb4b9f-j2jjd 2/2 Running 0 19m
istio-sidecar-injector-dbd67c88d-ffkgm 1/1 Running 0 19m
istio-statsd-prom-bridge-6dbb7dcc7f-fcl8f 1/1 Running 0 19m
istio-telemetry-54b5bf4847-5wq78 2/2 Running 0 19m
istio-tracing-67dbb5b89f-l52vk 1/1 Running 0 19m
prometheus-586d95b8d9-dw9xl 1/1 Running 0 19m
servicegraph-6d86dfc6cb-25qtp 1/1 Running 1 19m
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (JBEE-193) Java EE 8 Specs BOMs
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/JBEE-193?page=com.atlassian.jira.plugin.s... ]
Eduardo Martins edited comment on JBEE-193 at 6/11/18 3:39 AM:
---------------------------------------------------------------
Please note that on the submitted PR I did exclude jboss-servlet-api_3.1_spec from jboss-jacc-api_1.5_spec, but I'm not sure if that's the correct approach, perhaps a new release of such spec artifact should refer jboss-servlet-api_4.0_spec instead?
https://github.com/jboss/jboss-javaee-specs/pull/8/files#diff-600376dffeb...
was (Author: emmartins):
Please note that on the submitted PR I did exclude jboss-servlet-api_3.1_spec from jboss-jacc-api_1.5_spec, but I'm not sure if that's the correct approach, perhaps a new release of such spec artifact should refer jboss-servlet-api_4.0_spec instead?
> Java EE 8 Specs BOMs
> --------------------
>
> Key: JBEE-193
> URL: https://issues.jboss.org/browse/JBEE-193
> Project: JBoss JavaEE Spec APIs
> Issue Type: Task
> Components: jboss-javaee-specs
> Reporter: Eduardo Martins
> Assignee: Eduardo Martins
>
> Update the JBoss Java EE Specs BOMs with respect to Java EE 8, to be consumed by projects such as WildFly BOMs and Quickstarts.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month