[JBoss JIRA] Created: (JBREM-1286) Fix sources encoding to UTF-8
by Ondrej Zizka (JIRA)
Fix sources encoding to UTF-8
-----------------------------
Key: JBREM-1286
URL: https://issues.jboss.org/browse/JBREM-1286
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Ondrej Zizka
Compiling 395 source files to build/classes
src/main/org/jboss/remoting/callback/CallbackStore.java:79: unmappable character for encoding UTF-8
* Key for setting the file suffix to use for the callback objects written to disk. The default value is �ser�.
src/main/org/jboss/remoting/callback/CallbackStore.java:79: unmappable character for encoding UTF-8
* Key for setting the file suffix to use for the callback objects written to disk. The default value is �ser�.
2 errors
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[JBoss JIRA] Created: (JBREM-552) cannot init cause of ClassCastException
by John Mazzitelli (JIRA)
cannot init cause of ClassCastException
---------------------------------------
Key: JBREM-552
URL: http://jira.jboss.com/jira/browse/JBREM-552
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.0.0.Beta2 (Boon)
Reporter: John Mazzitelli
Assigned To: Tom Elrod
Priority: Minor
Fix For: 2.0.0.CR1 (Boon)
I'm in a catch clause within InvokerRegistry and I'm getting a weird exception thrown:
java.lang.IllegalStateException: Can't overwrite cause
at java.lang.Throwable.initCause(Throwable.java:320)
at org.jboss.remoting.InvokerRegistry.loadClientInvoker(InvokerRegistry.java:447)
at org.jboss.remoting.InvokerRegistry.createClientInvoker(InvokerRegistry.java:324)
at org.jboss.remoting.Client.connect(Client.java:385)
at org.jboss.on.communications.command.client.JBossRemotingRemoteCommunicator.getRemotingClient(JBossRemotingRemoteCommunicator.java:470)
at org.jboss.on.communications.command.client.JBossRemotingRemoteCommunicator.send(JBossRemotingRemoteCommunicator.java:430)
at org.jboss.on.communications.command.client.AbstractCommandClient.invoke(AbstractCommandClient.java:167)
at org.jboss.on.communications.command.client.ClientCommandSender.send(ClientCommandSender.java:820)
at org.jboss.on.communications.command.client.ServerPollingThread.run(ServerPollingThread.java:102)
Look at line 447 and you'll see it is trying to init the cause of a ClassNotFoundException. Running in a debugger, the newly constructed exception created on 446 has a null cause. Looking then at Throwable.initCause and you'll see a null cause causes this IllegalStateException to be thrown. The cause needs to be "this", not null (I don't know why, seems like it should also look for null, but whatever - that's the way the JDK is written).
The fix is simple - use the constructor that takes a throwable as its second parameter. Not sure why initCause it being used, as opposed to this constructor.
e.g.:
new ClassNotFoundException("Can not invoke loadClientInvokerClass method on " + transportFactoryClass, e);
(notice the ", e" parameter).
There are three other instances where initCause is called on ClassNotFoundException that also need to be fixed. See the other catch clauses in here.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[JBoss JIRA] Created: (JGRP-1250) Properties for each message
by Bela Ban (JIRA)
Properties for each message
---------------------------
Key: JGRP-1250
URL: https://jira.jboss.org/browse/JGRP-1250
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.12
JGroups already has the ability to bypass certain protocols, e.g. NO_FC set in a message bypasses any flow control layer.
It would be nice to do this for other protocols, too, e.g. SEQUENCER, but this needs to be done in a generic fashion.
What should be done is to use *properties*, e.g. +reliable-mcast, -frag, +flowcontrol, -bundling etc. Based on these flags, each protocol decides whether to handle (or not) a message. The properties should not take up *any* space in a message if not set.
This can probably be generalized, ie. by annotating a protocol with the props it provides, e.g. @Reliable @ReliableUnicast UNICAST, and by having code which matches the flags in a message and decides whether or not to process the message.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[JBoss JIRA] Created: (JBWEB-186) Using the native connector causes the JVM to crash when shutting down on Windows
by Mike Millson (JIRA)
Using the native connector causes the JVM to crash when shutting down on Windows
--------------------------------------------------------------------------------
Key: JBWEB-186
URL: https://jira.jboss.org/browse/JBWEB-186
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core
Affects Versions: JBossWeb-3.0.0.Beta7
Reporter: Mike Millson
Assignee: Remy Maucherat
Boss server is crashing with an "EXCEPTION_ACCESS_VIOLATION" once shutdown has started.
Setting a breakpoint in AccessLogValve.invoke() then doing shutdown, then releasing the break point crashes the JVM.
The fatal error log shows the following:
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0d74c90e, pid=3204, tid=5944
#
# JRE version: 6.0_20-b02
# Java VM: Java HotSpot(TM) Server VM (16.3-b01 mixed mode windows-x86 )
# Problematic frame:
# C [libapr-1.dll+0xc90e]
#
...
Current thread (0x05973400): JavaThread "http-127.0.0.1-8080-2" daemon [_thread_in_native, id=5944, stack(0x0efe0000,0x0f030000)]
...
Stack: [0x0efe0000,0x0f030000], sp=0x0f02f628, free space=13d0f02f15ck
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libapr-1.dll+0xc90e]
C [libtcnative-1.dll+0x1150]
j org.apache.tomcat.jni.Address.get(IJ)J+0
j org.apache.coyote.http11.Http11AprProcessor.action(Lorg/apache/coyote/ActionCode;Ljava/lang/Object;)V+196
j org.apache.coyote.Request.action(Lorg/apache/coyote/ActionCode;Ljava/lang/Object;)V+56
j org.apache.catalina.connector.Request.getRemoteAddr()Ljava/lang/String;+18
j org.apache.catalina.connector.Request.getRemoteHost()Ljava/lang/String;+19
j org.apache.catalina.valves.AccessLogValve$HostElement.addElement(Ljava/lang/StringBuffer;Ljava/util/Date;Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;J)V+2
j org.apache.catalina.valves.AccessLogValve.invoke(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;)V+115
...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[JBoss JIRA] Created: (JGRP-1194) Revisit implementation of TUNNEL and shared transport
by Vladimir Blagojevic (JIRA)
Revisit implementation of TUNNEL and shared transport
-----------------------------------------------------
Key: JGRP-1194
URL: https://jira.jboss.org/jira/browse/JGRP-1194
Project: JGroups
Issue Type: Task
Affects Versions: 2.9, 2.8
Reporter: Vladimir Blagojevic
Assignee: Vladimir Blagojevic
Fix For: 3.0
TUNNEL and shared transport are not supported at the moment (2.10.Alpha5). The main complexity behind TUNNEL and shared transport is that we have to change StubReceiver model. StubReceiver reads messages of the socket on the TUNNEL side. With shared transport turned on StubReceiver would have to be changed because we are receiving byte arrays for all channels sharing transport. We need some special StubReceiver multiplexer so to speak which will read messages and then pass off the byte arrays to other Receivers which will in turn pass them as messages to appropriate channel above transport. Each byte array passed around have to be pre appended with some identifier....and so on.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[JBoss JIRA] Created: (AS7-718) Jboss AS 7 request a version of tcnative that has not been released yet.
by Sebastian Otaegui (JIRA)
Jboss AS 7 request a version of tcnative that has not been released yet.
-------------------------------------------------------------------------
Key: AS7-718
URL: https://issues.jboss.org/browse/AS7-718
Project: Application Server 7
Issue Type: Bug
Components: Web
Affects Versions: 7.0.0.Beta3
Environment: ubuntu 11.04
x64
Reporter: Sebastian Otaegui
Assignee: Jason Greene
Priority: Trivial
Fix For: Open To Community
Jboss AS 7 request a version of tcnative that has not been released yet.
16:27:12,920 INFO [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-4) An older version 1.1.20 of the Apache Tomcat Native library is installed, while Tomcat recommends version greater then 1.1.21
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months