[JBoss JIRA] (AS7-4820) OSGi Start Level change doesn't iterate through intermediate levels
by David Bosschaert (JIRA)
David Bosschaert created AS7-4820:
-------------------------------------
Summary: OSGi Start Level change doesn't iterate through intermediate levels
Key: AS7-4820
URL: https://issues.jboss.org/browse/AS7-4820
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.1.2.Final (EAP)
Reporter: David Bosschaert
Assignee: Thomas Diesler
When changing the OSGi start level using the management API, the framework doesn't appear to go through the intermediate start levels.
When the following command is issued from the console:
{code}/subsystem=osgi:write-attribute(name=startlevel,value=3){code}
it seems like start level 2 is skipped in the framework from looking at the log:
{noformat}16:13:33,332 INFO [org.jboss.osgi.framework] (OSGi StartLevel Thread)
JBOSGI011007: Increasing start level from 1 to 3
16:13:33,332 INFO [org.jboss.osgi.framework] (OSGi StartLevel Thread)
JBOSGI011011: Starting bundles for start level: 3
16:13:33,332 INFO [org.jboss.osgi.framework] (OSGi StartLevel Thread)
JBOSGI011011: Starting bundles for start level: 3
16:13:33,333 INFO [system.bundle] (Thread-80) FrameworkEvent STARTLEVEL CHANGED{noformat}
The same happens when moving down in start level.
I haven't checked whether this is only a reporting issue or whether the intermediate start level are really skipped.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (JGRP-1453) Exception thrown when diagnostics address /port not equal to udp address /port
by Richard Achmatowicz (JIRA)
Richard Achmatowicz created JGRP-1453:
-----------------------------------------
Summary: Exception thrown when diagnostics address /port not equal to udp address /port
Key: JGRP-1453
URL: https://issues.jboss.org/browse/JGRP-1453
Project: JGroups
Issue Type: Bug
Affects Versions: 3.0.9
Environment: Fedora 16, x86_64
AS7 4.1.1.Final
Reporter: Richard Achmatowicz
Assignee: Bela Ban
Fix For: 3.0.10
When using JGroups as part of AS7 in the server configuration standalone-ha.xml, upon start up, we receive the exception:
{noformat}
09:52:36,831 ERROR [org.jboss.msc.service.fail] (pool-14-thread-1) MSC00001: Failed to start service jboss.jgroups.channel.web: org.jboss.msc.service.StartException in service jboss.jgroups.channel.web: java.lang.IllegalArgumentException: diagnostics_addr / diagnostics_port and mcast_addr / mcast_port have to be different
at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:62) [jboss-as-clustering-common-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_26]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_26]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_26]
Caused by: java.lang.IllegalArgumentException: diagnostics_addr / diagnostics_port and mcast_addr / mcast_port have to be different
at org.jgroups.protocols.UDP.createSockets(UDP.java:359) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.protocols.UDP.start(UDP.java:224) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:938) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.JChannel.startStack(JChannel.java:841) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.JChannel.connect(JChannel.java:277) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jgroups.JChannel.connect(JChannel.java:261) [jgroups-3.0.9.Final.jar:3.0.9.Final]
at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:44) [jboss-as-clustering-jgroups-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:59) [jboss-as-clustering-common-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
{noformat}
even when the address / port combination for udp and the address / port combination for diagnostics are distinct:
{noformat}
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
...
<socket-binding name="jgroups-diagnostics" port="0" multicast-address="ff0e::1" multicast-port="7500"/>
<socket-binding name="jgroups-mping" port="0" multicast-address="${jboss.default.multicast.address:ff0e::1}" multicast-port="45700"/>
<socket-binding name="jgroups-tcp" port="7600"/>
<socket-binding name="jgroups-tcp-fd" port="57600"/>
<socket-binding name="jgroups-udp" port="55200" multicast-address="${jboss.default.multicast.address:ff0e::1}" multicast-port="45688"/>
<socket-binding name="jgroups-udp-fd" port="54200"/>
<socket-binding name="modcluster" port="0" multicast-address="ff0e::1" multicast-port="23364"/>
...
</socket-binding-group>
{noformat}
The expected behaviour is that as long as the ports are distinct, we should be able to use the same mcast address for both udp and diagnostics.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (JGRP-1464) TCPConnectionMap: message from different JGroups version may cause OOME
by Bela Ban (JIRA)
Bela Ban created JGRP-1464:
------------------------------
Summary: TCPConnectionMap: message from different JGroups version may cause OOME
Key: JGRP-1464
URL: https://issues.jboss.org/browse/JGRP-1464
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.0.10, 3.1
If discard_incompatible_packets is enabled at the transport level, we discard packets from other JGroups versions. However, this is not done when TCP is used, at the TCPConnectionMap level.
When we read a packet from a different version, we first read the version, then the length. If the length is garbage, and we interpret it as a long, it can be huge, leading to an OOME.
[email from http://old.nabble.com/ArrayIndexOutOfBoundsException-in-3.09-ts33781725.h...]
I'd like to add some additional information to this post since I am seeing this crash the entire JVM. I've added some debugging statements to the TCPConnectionMap - ConnectionPeerReceiver.run method to try an understand the issue and recompiled the 3.0.9 jar (I am printing the len of the DataInputStream). It appears that when an incompatible message is received JG will discard some messages appropriately but not others. When some of these messages make it through they end up being of enormous size 1192331780 (or ~1.1 GB) which is enough to crash the JVM due to OOM (catching the OOMError in not sufficient in our configuration). Some are of size 0 as well... curious if they is some signed/unsigned conversion going on here? At any rate this is prohibiting us from moving to the latest version of JGroups in hopes of receiving better support.
2012-05-14 09:27:05,623 [Connection.Receiver [135.9.96.63:59953 - 135.9.128.31:7800],135.9.148.15_InterCluster-2.12,asmblade23-47979] jgroups.blocks.TCPConnectionMap$TCPConnection WARN - TG: DEBUG len=70
2012-05-14 09:27:05,624 [Connection.Receiver [135.9.96.63:59953 - 135.9.128.31:7800],135.9.148.15_InterCluster-2.12,asmblade23-47979] jgroups.blocks.TCPConnectionMap$TCPConnection WARN - TG: DEBUG len=70
2012-05-14 09:27:05,624 [OOB-1,135.9.148.15_InterCluster-2.12,asmblade23-47979] jgroups.protocols.TCP WARN - packet from 135.9.128.31:7800 has different version (2.6.10) from ours (3.0.10). Packet is discarded
2012-05-14 09:27:05,625 [OOB-2,135.9.148.15_InterCluster-2.12,asmblade23-47979] jgroups.protocols.TCP WARN - packet from 135.9.128.31:7800 has different version (2.6.10) from ours (3.0.10). Packet is discarded
2012-05-14 09:27:12,028 [ConnectionMap.Acceptor,null,null] jgroups.blocks.TCPConnectionMap$TCPConnection WARN - packet from /135.9.96.59:56077 has different version (2.6.10) from ours (3.0.10). This may cause problems
2012-05-14 09:27:12,030 [Connection.Receiver [135.9.96.63:7800 - 135.9.96.59:56077],135.9.148.15_InterCluster-2.12,asmblade23-47979] jgroups.blocks.TCPConnectionMap$TCPConnection WARN - TG: DEBUG len=0
2012-05-14 09:27:12,032 [Connection.Receiver [135.9.96.63:7800 - 135.9.96.59:56077],135.9.148.15_InterCluster-2.12,asmblade23-47979] jgroups.protocols.TCP ERROR - failed handling data from 135.9.96.59:7800
java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 2
at org.jgroups.protocols.TP.receive(TP.java:1200)
at org.jgroups.protocols.BasicTCP.receive(BasicTCP.java:104)
at org.jgroups.blocks.TCPConnectionMap$TCPConnection$ConnectionPeerReceiver.run(TCPConnectionMap.java:603)
at java.lang.Thread.run(Thread.java:769)
2012-05-14 09:27:12,034 [Connection.Receiver [135.9.96.63:7800 - 135.9.96.59:56077],135.9.148.15_InterCluster-2.12,asmblade23-47979] jgroups.blocks.TCPConnectionMap$TCPConnection WARN - TG: DEBUG len=1192331780
SOLUTION: discard packets from different JGroups versions in TCPConnectionMap.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] Created: (EJBTHREE-2248) singleton time bean starts with uninitialized EJBs
by Chris Wesdorp (JIRA)
singleton time bean starts with uninitialized EJBs
--------------------------------------------------
Key: EJBTHREE-2248
URL: https://issues.jboss.org/browse/EJBTHREE-2248
Project: EJB 3.0
Issue Type: Bug
Components: ejb3_1
Environment: jboss 6.0.0 final
Reporter: Chris Wesdorp
Attachments: jboss-timer-singleton.zip
During the deployment of a (large) EAR the following problem occurs. In one of the JARs a singleton EJB is included which has a method annotated with @Schedule. The time out for this schedule is every minute. This singleton has references to other EJBS in the project. But at deployment the singleton is loaded before the referenced EJBs are added registered in JNDI. When the time out of the singleton occurs a NullPointerException is thrown because the container isn't able to inject the other EJBs.
{noformat}2011-05-12 13:21:01,201 ERROR [org.jboss.ejb3.timerservice.mk2.task.TimerTask] (pool-99-thread-3) Error during retyring timeout for timer: [id=2d8011ca-66e3-4746-a035-3fa2b5a68263 timedObjectId=jboss.j2ee:ear=ht-ear-1.8.0-SNAPSHOT.ear,jar=ht-system.jar,name=BatchExecutor,service=EJB3 auto-timer?:true persistent?:true timerService=org.jboss.ejb3.timerservice.mk2.TimerServiceImpl@1d261c7e initialExpiration=2011-05-10 00:00:00.0 intervalDuration(in milli sec)=0 nextExpiration=Tue May 10 16:03:00 CEST 2011 timerState=RETRY_TIMEOUT: javax.ejb.EJBException: java.lang.NullPointerException
at org.jboss.ejb3.singleton.impl.container.SingletonEJBInstanceManagerImpl.create(SingletonEJBInstanceManagerImpl.java:137) [:1.0.0-alpha-28]
at org.jboss.ejb3.singleton.impl.container.SingletonEJBInstanceManagerImpl.get(SingletonEJBInstanceManagerImpl.java:152) [:1.0.0-alpha-28]
at org.jboss.ejb3.singleton.impl.container.SingletonContainer.invoke(SingletonContainer.java:201) [:1.0.0-alpha-28]
at org.jboss.ejb3.singleton.aop.impl.AOPBasedSingletonContainer.callTimeout(AOPBasedSingletonContainer.java:886) [:1.0.0-alpha-28]
at org.jboss.ejb3.timerservice.mk2.task.CalendarTimerTask.callTimeout(CalendarTimerTask.java:80) [:1.0.0-alpha-13]
at org.jboss.ejb3.timerservice.mk2.task.TimerTask.run(TimerTask.java:127) [:1.0.0-alpha-13]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_24]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_24]
at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_24]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98) [:1.6.0_24]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206) [:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
Caused by: org.jboss.injection.manager.spi.InjectionException: javax.naming.NamingException: Could not dereference object [Root exception is javax.naming.NamingException: Could not dereference object [Root exception is javax.naming.NameNotFoundException: ConfigDAO not bound]]
at org.jboss.injection.injector.EEInjector.inject(EEInjector.java:87) [:1.0.0-alpha-6]
at org.jboss.injection.manager.core.DefaultInjectionContext.proceed(DefaultInjectionContext.java:58) [:1.0.0-alpha-6]
at org.jboss.injection.manager.core.DefaultInjectionManager.inject(DefaultInjectionManager.java:58) [:1.0.0-alpha-6]
at org.jboss.injection.manager.core.DefaultInjectionManager.inject(DefaultInjectionManager.java:64) [:1.0.0-alpha-6]
at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:140) [:1.7.17]
at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:125) [:1.7.17]
at org.jboss.ejb3.core.context.CurrentInvocationContextInterceptor.invoke(CurrentInvocationContextInterceptor.java:47) [:1.7.17]
at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:116) [:1.7.17]
at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67) [:1.0.1]
at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:116) [:1.7.17]
at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1363) [:1.7.17]
at org.jboss.ejb3.singleton.aop.impl.AOPBasedSingletonContainer.postConstruct(AOPBasedSingletonContainer.java:759) [:1.0.0-alpha-28]
at org.jboss.ejb3.singleton.impl.container.SingletonEJBInstanceManagerImpl.create(SingletonEJBInstanceManagerImpl.java:133) [:1.0.0-alpha-28]
... 13 more{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (AS7-4816) SC 500 returned to the HTTP client on server shutdown
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-4816:
-----------------------------------
Summary: SC 500 returned to the HTTP client on server shutdown
Key: AS7-4816
URL: https://issues.jboss.org/browse/AS7-4816
Project: Application Server 7
Issue Type: Bug
Components: Clustering, Web
Affects Versions: 7.1.2.Final (EAP)
Reporter: Radoslav Husar
Assignee: Paul Ferraro
Fix For: 7.1.3.Final (EAP)
Filing this issue to investigate why we are seeing so many 500 status codes returned to the client on *graceful* server shutdown. Nothing suspicious in the server log.
{noformat}
2012/05/13 18:19:50:360 EDT [WARN ][Runner - 1316] SFCORE_LOG - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Invalid response code: 500 Content: >
2012/05/13 18:19:50:360 EDT [WARN ][Runner - 1620] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Invalid response code: 500 Content: >
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months