[JBoss JIRA] (JBAS-4752) Session Expiration should also flush the JBoss Authentication Cache
by Mandar Joshi (JIRA)
[ https://issues.jboss.org/browse/JBAS-4752?page=com.atlassian.jira.plugin.... ]
Mandar Joshi commented on JBAS-4752:
------------------------------------
I am working on JBOSS 4.2.3. I am having one issue. I deploy my application on JBOSS. I use spnego protocol for Single Sign On. I am running into an issue where the application is running out of memory. I took heap dumps at regular intervals. I open every dump in Eclipse Memory Analyzer. I open the dominator_tree. I see a big percentage of entries (it grows from small percentage to a bigger one) occupied by class org.jboss.util.TimedCachePolicy. There one entry for each https request to the application. I think they should not get accumulated. My question is if this fix (JBAS-4752) would resolve this issue? Any suggestions / recommendations / questions / details you need?
Thanks
> Session Expiration should also flush the JBoss Authentication Cache
> -------------------------------------------------------------------
>
> Key: JBAS-4752
> URL: https://issues.jboss.org/browse/JBAS-4752
> Project: Application Server 3 4 5 and 6
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Security, Web (Tomcat) service
> Affects Versions: JBossAS-4.2.0.GA
> Reporter: Anil Saldhana
> Assignee: Marcus Moyses
> Fix For: JBossAS-4.2.2.GA, JBossAS-5.0.1.GA
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (JBAS-9543) Jmx console reinvoke operation results in 500 error code
by Jay Kumar SenSharma (JIRA)
[ https://issues.jboss.org/browse/JBAS-9543?page=com.atlassian.jira.plugin.... ]
Jay Kumar SenSharma edited comment on JBAS-9543 at 7/2/13 12:46 AM:
--------------------------------------------------------------------
This is the suggested fix for the issue "JBPAPP-10733-UPDATED.patch" to include UTF-8 character encoding on the "displayOpResult.jsp" sothat while using POST data with special characters like + or / it will not fail.
was (Author: jaysensharma):
This is the suggested fix for the issue
> Jmx console reinvoke operation results in 500 error code
> --------------------------------------------------------
>
> Key: JBAS-9543
> URL: https://issues.jboss.org/browse/JBAS-9543
> Project: Application Server 3 4 5 and 6
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JMX
> Affects Versions: 6.1.0
> Environment: All
> Reporter: Jay Kumar SenSharma
> Labels: jmx-console
> Attachments: JBPAPP-10733-UPDATED.patch
>
>
> 1.login to JMX console
> 2.click on org.jboss.system.server.ServerInfo
> 3.click on listThreadCpuUtilization or listThreadDump
> 4.click reinvioke operation.
> 5.error on browser is 500
> 6.error on server log is
> ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/jmx-console].[HtmlAdaptor]] Servlet.service() for servlet HtmlAdaptor threw exception
> javax.servlet.ServletException: Operation invoke prohibited.
> at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOpByName(HtmlAdaptorServlet.java:319)
> at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:106)
> at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doGet(HtmlAdaptorServlet.java:81)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:534)
> at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95)
> at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.internalProcess(ActiveRequestResponseCacheValve.java:74)
> at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:47)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:599)
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:451)
> at java.lang.Thread.run(Thread.java:722)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (JBAS-9543) Jmx console reinvoke operation results in 500 error code
by Jay Kumar SenSharma (JIRA)
[ https://issues.jboss.org/browse/JBAS-9543?page=com.atlassian.jira.plugin.... ]
Jay Kumar SenSharma updated JBAS-9543:
--------------------------------------
Attachment: JBPAPP-10733-UPDATED.patch
This is the suggested fix for the issue
> Jmx console reinvoke operation results in 500 error code
> --------------------------------------------------------
>
> Key: JBAS-9543
> URL: https://issues.jboss.org/browse/JBAS-9543
> Project: Application Server 3 4 5 and 6
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JMX
> Affects Versions: 6.1.0
> Environment: All
> Reporter: Jay Kumar SenSharma
> Labels: jmx-console
> Attachments: JBPAPP-10733-UPDATED.patch
>
>
> 1.login to JMX console
> 2.click on org.jboss.system.server.ServerInfo
> 3.click on listThreadCpuUtilization or listThreadDump
> 4.click reinvioke operation.
> 5.error on browser is 500
> 6.error on server log is
> ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/jmx-console].[HtmlAdaptor]] Servlet.service() for servlet HtmlAdaptor threw exception
> javax.servlet.ServletException: Operation invoke prohibited.
> at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOpByName(HtmlAdaptorServlet.java:319)
> at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:106)
> at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doGet(HtmlAdaptorServlet.java:81)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:534)
> at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95)
> at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.internalProcess(ActiveRequestResponseCacheValve.java:74)
> at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:47)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:599)
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:451)
> at java.lang.Thread.run(Thread.java:722)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (JGRP-1644) NAKACK2 violates FIFO property
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1644?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1644:
--------------------------------
Akka / scala code, ouch ! :-)
Hmm, I'll try to see if I can decipher this to see if there's a flaw in the logic of your program...
One thing you could do meanwhile is to enable TRACE for NAKACK2 and search for "delivering". You should see something like this below:
{noformat}
5046 [TRACE] NAKACK2: B: received A#26 - #26 (1 messages)
5046 [TRACE] NAKACK2: B: delivering #26 - #26 (1 messages)
5062 [TRACE] NAKACK2: B: received A#27 - #27 (1 messages)
5062 [TRACE] NAKACK2: B: delivering #27 - #27 (1 messages)
5095 [TRACE] NAKACK2: B: received A#28 - #28 (1 messages)
5096 [TRACE] NAKACK2: B: delivering #28 - #28 (1 messages)
5163 [TRACE] NAKACK2: B: received A#29 - #29 (1 messages)
5163 [TRACE] NAKACK2: B: delivering #29 - #29 (1 messages)
5297 [TRACE] NAKACK2: B: received A#30 - #30 (1 messages)
5298 [TRACE] NAKACK2: B: delivering #30 - #30 (1 messages)
5313 [TRACE] NAKACK2: B: received A#31 - #31 (1 messages)
{noformat}
If you grep for "delivering" and perhaps pipe different senders into different files, you should see monotonically increasing sequence numbers per sender. E.g. above we see messages 26-31 from A being multicast and the receiver here is B.
> NAKACK2 violates FIFO property
> ------------------------------
>
> Key: JGRP-1644
> URL: https://issues.jboss.org/browse/JGRP-1644
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3.1
> Environment: Ubuntu 12.04 LTS, kernel 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:52:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux, Java 1.7.0_21
> Reporter: Vadim Tsesko
> Assignee: Bela Ban
> Fix For: 3.4
>
> Attachments: TCP-NAKACK2.png, UDP-NAKACK2-NAKACK.png
>
>
> In the [documentation documentation|http://www.jgroups.org/manual/html/protlist.html#ReliableMe...] it is stated that:
> {quote}
> NAKACK provides reliable delivery and FIFO (= First In First Out) properties for messages sent to all nodes in a cluster.
> {quote}
> and
> {quote}
> NAKACK2 was introduced in 3.1 and is a successor to NAKACK (at some point it will replace NAKACK). It has the same properties as NAKACK, but its implementation is faster and uses less memory, plus it creates fewer tasks in the timer.
> {quote}
> I have observed that sometimes multicast messages are received out of order.
> We use the following protocol stack configuration:
> {code:xml}
> <config xmlns="urn:org:jgroups"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.3.xsd">
> <UDP bind_addr="match-interface:$interface"
> bind_interface="$interface"
> bind_port="$unicastPort"
> ip_ttl="128"
> mcast_addr="$multicastGroup"
> mcast_port="$multicastPort"
> singleton_name="udp-transport"/>
> <PING return_entire_cache="true"
> break_on_coord_rsp="false"/>
> <MERGE3/>
> <FD_SOCK/>
> <FD_ALL/>
> <VERIFY_SUSPECT/>
> <BARRIER/>
> <pbcast.NAKACK print_stability_history_on_failed_xmit="true"/>
> <pbcast.STABLE/>
> <pbcast.GMS/>
> <MFC max_credits="8M"/>
> <FRAG2/>
> <RSVP/>
> </config>
> {code}
> As you can see, mostly we use the defaults.
> The messages are being sent from a single thread using the following code:
> {code:java}
> channel.send(new Message(null, msg))
> {code}
> Each message has size from 300 KB up to 4 MB. The message rate is 1-5 messages per second.
> We have a sequential counter inside each message being sent. Sometimes the messages are received out of order, for instance:
> {code}
> #1198
> #1199
> #1200
> #1202
> #1201
> #1203
> #1204
> {code}
> If we replace {{NAKACK2}} by {{NAKACK}} the problem disappears -- everything works as expected (FIFO).
> If we replace JGroups-based transport by ZeroMQ-based transport (actually running over EPGM and being used for a year) everything works as expected (FIFO) -- just to let you know, that there are no bugs in out message numbering logic.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (JGRP-1643) Change license to Apache License 2.0
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1643?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1643:
--------------------------------
Example command:
{noformat}
find src bin conf doc tests -exec git blame -f {} \;|grep chrislott
{noformat}
> Change license to Apache License 2.0
> ------------------------------------
>
> Key: JGRP-1643
> URL: https://issues.jboss.org/browse/JGRP-1643
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> Change the license from LGPL 2.1 to AL 2.0. This includes the following tasks:
> * Identify all contributors who have code in master (to be 3.4)
> * Remove contributors who are Red Hat employees (work-for-hire)
> * Remove contributors who were Red Hat employees at the time of the contribution
> * Contact the remaining contributors and ask for their permission to change the license
> * Change the web site to list both LGPL 2.1 (<= 3.3) and AL 2.0 (>= 3.4) licenses
> * Change LICENSE in master: include both licenses, state that code <= 3.3 is licensed under LGPL 2.1 and later code is licensed under AL 2.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (WFLY-1146) Export remoting-JMX address via JVM instrumentation buffer
by James Livingston (JIRA)
[ https://issues.jboss.org/browse/WFLY-1146?page=com.atlassian.jira.plugin.... ]
James Livingston commented on WFLY-1146:
----------------------------------------
If we don't want this that's fine.
Although it does use internal Sun API which is obviously not portable or stable, if it's run on a JVM which does not support it, it will simply log the CFNE/MNFE at debug level and continue as it currently behaves. Supporting compiling without such a VM could trivially be done by using reflection.
I don't see how this would break non-local authentication. If the user manually enters the service URL then the data in the instrumentation buffer is not used, so it shouldn't make a difference. If the user picks the process from the list, then JConsole can't (at least in my experience) connect at all because it doesn't know to use the remoting service URL rather than the Sun JDK standard RMI one.
> Export remoting-JMX address via JVM instrumentation buffer
> ----------------------------------------------------------
>
> Key: WFLY-1146
> URL: https://issues.jboss.org/browse/WFLY-1146
> Project: WildFly
> Issue Type: Feature Request
> Components: JMX
> Reporter: James Livingston
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.Alpha3
>
>
> Currently to connect to the AS with JConsole you need to manually enter the service:jmx:remoting-jmx:// address. When the local process connection is used, it retrieves the connection address via the Sun JDK management instrumentation buffer.
> The exported address can be set via sun.management.ConnectorAddressLink.export(), and doing that would allow JConsole to connect without typing in the address (although still obviously require the jars to be on the classpath).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (JBREM-1321) Null pointer when deploying repeatedly via arquillian - EAP 6.1
by John Ament (JIRA)
John Ament created JBREM-1321:
---------------------------------
Summary: Null pointer when deploying repeatedly via arquillian - EAP 6.1
Key: JBREM-1321
URL: https://issues.jboss.org/browse/JBREM-1321
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: John Ament
I am seeing a NullPointerException consistently after a while for tests running. This is the stack trace. This is in EAP 6.1
2013-06-19 10:06:55,035 [Remoting "management-client" read-1] ERROR org.xnio.listener - A channel event listener threw an exception
java.lang.NullPointerException
at org.jboss.remoting3.remote.IntIndexHashMap.resize(IntIndexHashMap.java:461)
at org.jboss.remoting3.remote.IntIndexHashMap.doPut(IntIndexHashMap.java:406)
at org.jboss.remoting3.remote.IntIndexHashMap.putIfAbsent(IntIndexHashMap.java:154)
at org.jboss.remoting3.remote.RemoteConnectionChannel.handleMessageData(RemoteConnectionChannel.java:424)
at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:234)
at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:180)
at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (WFLY-65) EjbUtilities is used without regard for dependencies
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-65?page=com.atlassian.jira.plugin.sy... ]
RH Bugzilla Integration commented on WFLY-65:
---------------------------------------------
Paul Gier <pgier(a)redhat.com> made a comment on [bug 950864|https://bugzilla.redhat.com/show_bug.cgi?id=950864]
Looks like this fix was included in 6.1.0 but was never verified by QA. Marking for 6.1.1 to be tested.
> EjbUtilities is used without regard for dependencies
> ----------------------------------------------------
>
> Key: WFLY-65
> URL: https://issues.jboss.org/browse/WFLY-65
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Stuart Douglas
> Assignee: jaikiran pai
> Fix For: 8.0.0.Alpha1
>
>
> org.jboss.as.ejb3.component.EJBUtilities is used to get services in the EJB subsystem, without setting up proper dependencies (e.g. in org.jboss.as.ejb3.component.EJBComponentCreateService#getEJBUtilities). Occasionally this can cause problems at startup as EJBUtilities can end up being null for some EJB's.
> We should probably just remove this class, or at the very least make sure it is injected properly and not looked up.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years