[JBoss JIRA] (JGRP-2311) tshark/wireshark support
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2311?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2311:
---------------------------
Description:
1. Dump contents of wireshark/tshark/tcpdump-generated (PCAP) files (using {{ParseMessages}}
2. Do this dynamically, e.g. `tshark -Tfields -e data` | java ParseMessages
In the second instantiation, ParseMessages would read packets from stdin.
was:
1. Dump contents of wireshark/tahsrk/tcpdump-generated (PCAP) files (using {{ParseMessages}}
2. Do this dynamically, e.g. `tshark -Tfields -e data` | java ParseMessages
In the second instantiation, ParseMessages would read packets from stdin.
> tshark/wireshark support
> ------------------------
>
> Key: JGRP-2311
> URL: https://issues.jboss.org/browse/JGRP-2311
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.0
>
> Attachments: tshark-convert.py
>
>
> 1. Dump contents of wireshark/tshark/tcpdump-generated (PCAP) files (using {{ParseMessages}}
> 2. Do this dynamically, e.g. `tshark -Tfields -e data` | java ParseMessages
> In the second instantiation, ParseMessages would read packets from stdin.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-11130) javax.security.enterprise.SecurityContext.isCallerInRole throws NullPointerException if the caller is not authenticated (New Java EE 8 Security)
by Lukas Kuzmiak (Jira)
[ https://issues.jboss.org/browse/WFLY-11130?page=com.atlassian.jira.plugin... ]
Lukas Kuzmiak commented on WFLY-11130:
--------------------------------------
This still happens to me with 18.0.0.Final nowadays, is it a bug?
{{Caused by: java.lang.NullPointerException
at org.glassfish.soteria@1.0.1//org.glassfish.soteria.authorization.JACC.fromSubject(JACC.java:142)
at org.glassfish.soteria@1.0.1//org.glassfish.soteria.authorization.JACC.hasPermission(JACC.java:101)
at org.glassfish.soteria@1.0.1//org.glassfish.soteria.authorization.JACC.isCallerInRole(JACC.java:56)
at org.glassfish.soteria@1.0.1//org.glassfish.soteria.authorization.spi.impl.ReflectionAndJaccCallerDetailsResolver.isCallerInRole(ReflectionAndJaccCallerDetailsResolver.java:58)
at org.glassfish.soteria@1.0.1//org.glassfish.soteria.SecurityContextImpl.isCallerInRole(SecurityContextImpl.java:65)
}}
> javax.security.enterprise.SecurityContext.isCallerInRole throws NullPointerException if the caller is not authenticated (New Java EE 8 Security)
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11130
> URL: https://issues.jboss.org/browse/WFLY-11130
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 14.0.1.Final
> Reporter: Instantiation Exception
> Priority: Major
>
> I tried to use new Java EE 8 Security API and noticed that javax.security.enterprise.SecurityContext.isCallerInRole throws NullPointerException if the caller is not authenticated. But according to JavaDoc it should return false in this situation.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-11130) javax.security.enterprise.SecurityContext.isCallerInRole throws NullPointerException if the caller is not authenticated (New Java EE 8 Security)
by Lukas Kuzmiak (Jira)
[ https://issues.jboss.org/browse/WFLY-11130?page=com.atlassian.jira.plugin... ]
Lukas Kuzmiak edited comment on WFLY-11130 at 11/11/19 2:16 AM:
----------------------------------------------------------------
This still happens to me with 18.0.0.Final nowadays, is it a bug?
{noformat}
Caused by: java.lang.NullPointerException
at org.glassfish.soteria@1.0.1//org.glassfish.soteria.authorization.JACC.fromSubject(JACC.java:142)
at org.glassfish.soteria@1.0.1//org.glassfish.soteria.authorization.JACC.hasPermission(JACC.java:101)
at org.glassfish.soteria@1.0.1//org.glassfish.soteria.authorization.JACC.isCallerInRole(JACC.java:56)
at org.glassfish.soteria@1.0.1//org.glassfish.soteria.authorization.spi.impl.ReflectionAndJaccCallerDetailsResolver.isCallerInRole(ReflectionAndJaccCallerDetailsResolver.java:58)
at org.glassfish.soteria@1.0.1//org.glassfish.soteria.SecurityContextImpl.isCallerInRole(SecurityContextImpl.java:65)
{noformat}
was (Author: lukaskuzmiak):
This still happens to me with 18.0.0.Final nowadays, is it a bug?
{{Caused by: java.lang.NullPointerException
at org.glassfish.soteria@1.0.1//org.glassfish.soteria.authorization.JACC.fromSubject(JACC.java:142)
at org.glassfish.soteria@1.0.1//org.glassfish.soteria.authorization.JACC.hasPermission(JACC.java:101)
at org.glassfish.soteria@1.0.1//org.glassfish.soteria.authorization.JACC.isCallerInRole(JACC.java:56)
at org.glassfish.soteria@1.0.1//org.glassfish.soteria.authorization.spi.impl.ReflectionAndJaccCallerDetailsResolver.isCallerInRole(ReflectionAndJaccCallerDetailsResolver.java:58)
at org.glassfish.soteria@1.0.1//org.glassfish.soteria.SecurityContextImpl.isCallerInRole(SecurityContextImpl.java:65)
}}
> javax.security.enterprise.SecurityContext.isCallerInRole throws NullPointerException if the caller is not authenticated (New Java EE 8 Security)
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11130
> URL: https://issues.jboss.org/browse/WFLY-11130
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 14.0.1.Final
> Reporter: Instantiation Exception
> Priority: Major
>
> I tried to use new Java EE 8 Security API and noticed that javax.security.enterprise.SecurityContext.isCallerInRole throws NullPointerException if the caller is not authenticated. But according to JavaDoc it should return false in this situation.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4731) Working with Long field
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-4731?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-4731:
--------------------------------
Sprint: 2019 Week 44-46 (from Okt 28)
> Working with Long field
> -----------------------
>
> Key: DROOLS-4731
> URL: https://issues.jboss.org/browse/DROOLS-4731
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.28.0.Final
> Reporter: Pavel Tavoda
> Assignee: Mario Fusco
> Priority: Major
> Attachments: error-with-long.zip
>
>
> Setting long field value in THEN:
> This are 3 different problems:
> 1) package as kjar with 'mvn clean install' result in "Error: unable to resolve method using strict-mode: org.drools.core.spi.Activation.setValue(java.lang.Integer)"
> RESULT:
> IntInRuleJava.drl - FAIL
> IntInRuleMvel.drl - FAIL
> LongInRuleJava.drl - OK
> LongInRuleMvel.drl - FAIL
> LongError.gdst - FAIL
> 2) package as kjar with 'mvn clean install -Ddrools.dialect.mvel.strict=false', same error on different files:
> IntInRuleJava.drl - FAIL
> IntInRuleMvel.drl - OK
> LongInRuleJava.drl - OK
> LongInRuleMvel.drl - OK
> LongError.gdst - OK
> 3) with 'mvn clean install -DgenerateModel=YES' it result in 'incompatible types: int cannot be converted to java.lang.Long', setting strict false have no influence on result
> IntInRuleJava.drl - FAIL
> IntInRuleMvel.drl - FAIL
> LongInRuleJava.drl - OK
> LongInRuleMvel.drl - OK
> LongError.gdst - FAIL
> Setting 'drools.dialect.mvel.strict' in kmodule.xml doesn't work.
> Example project attached.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JGRP-2396) increasing networkdata, cpu and heap
by Rob van der Boom (Jira)
[ https://issues.jboss.org/browse/JGRP-2396?page=com.atlassian.jira.plugin.... ]
Rob van der Boom commented on JGRP-2396:
----------------------------------------
I added a jstack (jstack -l -e) dump, is this something to work with ?
> increasing networkdata, cpu and heap
> ------------------------------------
>
> Key: JGRP-2396
> URL: https://issues.jboss.org/browse/JGRP-2396
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.19
> Reporter: Rob van der Boom
> Assignee: Bela Ban
> Priority: Major
> Attachments: Schermafbeelding 2019-11-08 om 15.43.04.png, Schermafbeelding 2019-11-08 om 15.44.52.png, Schermafbeelding 2019-11-08 om 16.00.48.png, jstack-production-pod0.dump, standalone-ha.xml
>
>
> hey,
> we have an keycloak (sso) setup, version 7.0.1 running in kubernetes - aws.
> Its build on wildfly 17, infinispan 9.4 and jgroups 4.0.19.
> We have 3 pods running in standalone-ha with cache setup on distribution (all 3 nodes - so equivalent to replication)
> ISSUE:
> We see a slowly growing of networkstatistics, heap and cpu, while the number of sessions in keycloak (cached) remain almost stable.
> The cpu growth is caused by the TQbundler process, which explaines the networkdata growth. It looks like this is causing also a memory leakage..
> every 5 days we have to restart the pods and then every resets to a very low level including the heap. this while all sessions are still valid and cached.
> The only issue i could find maybe related to this is:
> https://issues.jboss.org/browse/JGRP-2382?jql=project%20%3D%20JGRP%20AND%...
> Could this be the same issue and does it also cause increasing network and cpu (since that is why we have to restart, the heap has much space left !).
> And if so how does this issue continue since for us its a major issue.
> We als had this issue already in keycloak 5 (wildfly 15), thats why we upgraded to the latest available version.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JGRP-2396) increasing networkdata, cpu and heap
by Rob van der Boom (Jira)
[ https://issues.jboss.org/browse/JGRP-2396?page=com.atlassian.jira.plugin.... ]
Rob van der Boom updated JGRP-2396:
-----------------------------------
Attachment: jstack-production-pod0.dump
> increasing networkdata, cpu and heap
> ------------------------------------
>
> Key: JGRP-2396
> URL: https://issues.jboss.org/browse/JGRP-2396
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.19
> Reporter: Rob van der Boom
> Assignee: Bela Ban
> Priority: Major
> Attachments: Schermafbeelding 2019-11-08 om 15.43.04.png, Schermafbeelding 2019-11-08 om 15.44.52.png, Schermafbeelding 2019-11-08 om 16.00.48.png, jstack-production-pod0.dump, standalone-ha.xml
>
>
> hey,
> we have an keycloak (sso) setup, version 7.0.1 running in kubernetes - aws.
> Its build on wildfly 17, infinispan 9.4 and jgroups 4.0.19.
> We have 3 pods running in standalone-ha with cache setup on distribution (all 3 nodes - so equivalent to replication)
> ISSUE:
> We see a slowly growing of networkstatistics, heap and cpu, while the number of sessions in keycloak (cached) remain almost stable.
> The cpu growth is caused by the TQbundler process, which explaines the networkdata growth. It looks like this is causing also a memory leakage..
> every 5 days we have to restart the pods and then every resets to a very low level including the heap. this while all sessions are still valid and cached.
> The only issue i could find maybe related to this is:
> https://issues.jboss.org/browse/JGRP-2382?jql=project%20%3D%20JGRP%20AND%...
> Could this be the same issue and does it also cause increasing network and cpu (since that is why we have to restart, the heap has much space left !).
> And if so how does this issue continue since for us its a major issue.
> We als had this issue already in keycloak 5 (wildfly 15), thats why we upgraded to the latest available version.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months