[JBoss JIRA] Resolved: (JBWEB-38) PDf file serving speed should be increased.static file serving speed by byte range req should be increased
by Remy Maucherat (JIRA)
[ https://jira.jboss.org/jira/browse/JBWEB-38?page=com.atlassian.jira.plugi... ]
Remy Maucherat resolved JBWEB-38.
---------------------------------
Resolution: Won't Fix
See https://issues.apache.org/bugzilla/show_bug.cgi?id=45419
I think the most realistic solution would be to use a filter or valve to add the header.
> PDf file serving speed should be increased.static file serving speed by byte range req should be increased
> -----------------------------------------------------------------------------------------------------------
>
> Key: JBWEB-38
> URL: https://jira.jboss.org/jira/browse/JBWEB-38
> Project: JBoss Web
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Core
> Affects Versions: JBossWeb embedded - AS 4.0.0
> Environment: jboss 3.2.5 , windows/unix
> Reporter: dev per
> Assignee: Remy Maucherat
> Attachments: test.war
>
>
> Our application serves pdf file over the web.This how we do pdf streaming
> 1.browser sends a request for a pdf file
> 2.Our application adds a header Accpet-Ranges which servers like a flag by which browser understands that this server can send response in byte ranges(streaming).
> 3.Jboss sends the header set by our application along with so many other headers to browser. Jboss tries to send some pdf content
> 4. As soon as Browser sees the flag and it sends request to Jboss to send pdf content in ranges of bytes .browser can request for any rangesof bytes withing contnet length of file.One request may have multiple byte range requests
> 4.Jboss sends the requested bytes to browser.
> Though streaming happens when we open Pdf , sometimes intial appearance of pdf in the browser take a longer time.
> To debug this problem we used a http sniffer and tried to open some other pdfs avilable over internet.This what we found by tracking our application and other pdfs in inetrnet
> a.PDfs over the internet opens up faster than our application pdfs over internet.
> b.reason is those server sends only few thousands of bytes and responds to byte range req from browser.
> c.But jboss application server we use tries to send few hunderd thousand bytes before it services the byte range request from browser.this makes the initial pdf appearance slow.
> Note:the req and resp header of inetrepdfs are same as what we set in our application .
> I think modifying tomcat DefaultServlet , to send only some thousand bytes and service byte range requests as soon as they are recieved , will fix the problem.
--
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
18 years
[JBoss JIRA] Created: (JBPORTAL-2082) ReadOnlyException - sample weather - jbp 2.7.0.ALPHA
by ced ced (JIRA)
ReadOnlyException - sample weather - jbp 2.7.0.ALPHA
----------------------------------------------------
Key: JBPORTAL-2082
URL: https://jira.jboss.org/jira/browse/JBPORTAL-2082
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: ced ced
I test the sample weather with jbossportal 2.7.0.ALPHA, I change the zip code and I have this exception :
I search in the source code and I looked in the class AbstractInstanceDefinition that the method getAccessMode() return always the read-only value.
Why the class PersistentInstanceDefinition does not implement in this method getAccessMode() ?
2008-07-23 22:24:53,484 ERROR [STDERR] javax.portlet.ReadOnlyException: Key RssXml cannot be written
2008-07-23 22:24:53,484 ERROR [STDERR] at org.jboss.portal.portlet.impl.jsr168.api.PortletPreferenc
esImpl.setValue(PortletPreferencesImpl.java:250)
2008-07-23 22:24:53,484 ERROR [STDERR] at org.jboss.portal.core.samples.weather.WeatherPortlet.proc
essAction(WeatherPortlet.java:211)
2008-07-23 22:24:53,500 ERROR [STDERR] at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl
$Invoker.doFilter(PortletContainerImpl.java:557)
2008-07-23 22:24:53,500 ERROR [STDERR] at org.jboss.portal.portlet.impl.jsr168.api.FilterChainImpl.
doFilter(FilterChainImpl.java:109)
2008-07-23 22:24:53,500 ERROR [STDERR] at org.jboss.portal.portlet.impl.jsr168.api.FilterChainImpl.
doFilter(FilterChainImpl.java:72)
2008-07-23 22:24:53,500 ERROR [STDERR] at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl
.dispatch(PortletContainerImpl.java:505)
2008-07-23 22:24:53,500 ERROR [STDERR] at org.jboss.portal.portlet.container.ContainerPortletDispat
cher.invoke(ContainerPortletDispatcher.java:42)
2008-07-23 22:24:53,500 ERROR [STDERR] at org.jboss.portal.portlet.PortletInvokerInterceptor.invoke
(PortletInvokerInterceptor.java:82)
2008-07-23 22:24:53,500 ERROR [STDERR] at org.jboss.portal.core.aspects.portlet.TransactionIntercep
tor.org$jboss$portal$core$aspects$portlet$TransactionInterceptor$invokeNotSupported$aop(TransactionI
nterceptor.java:97)
2008-07-23 22:24:53,500 ERROR [STDERR] at org.jboss.portal.core.aspects.portlet.TransactionIntercep
tor$invokeNotSupported_N6922078035659651697.invokeNext(TransactionInterceptor$invokeNotSupported_N69
22078035659651697.java)
2008-07-23 22:24:53,500 ERROR [STDERR] at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:
66)
2008-07-23 22:24:53,500 ERROR [STDERR] at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(Tx
Interceptor.java:112)
2008-07-23 22:24:53,500 ERROR [STDERR] at org.jboss.portal.core.aspects.portlet.TransactionIntercep
tor$invokeNotSupported_N6922078035659651697.invokeNext(TransactionInterceptor$invokeNotSupported_N69
22078035659651697.java)
2008-07-23 22:24:53,500 ERROR [STDERR] at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:
66)
--
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
18 years
[JBoss JIRA] Created: (JBAS-4872) Invalid URI if the jboss.bind.address is IPv6
by Takayoshi Kimura (JIRA)
Invalid URI if the jboss.bind.address is IPv6
---------------------------------------------
Key: JBAS-4872
URL: http://jira.jboss.com/jira/browse/JBAS-4872
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Remoting
Affects Versions: JBossAS-4.2.1.GA
Reporter: Takayoshi Kimura
Assigned To: Ron Sigal
JBossRemoting uses jboss.bind.address in URI like the following:
socket://${jboss.bind.address}:4446/?datatype=invocation
However, if the jboss.bind.address is IPv6, it should be inside
of square brackets.
Invalid URI
socket://::1:4446/?datatype=invocation
Valid URI
socket://[::1]:4446/?datatype=invocation
To reproduce this issue:
Run JBoss instance by the following commend on IPv6 enabled system.
$ ./run.sh -c default -b ::1
Workaround:
Edit JBossRemoting URL not to use jboss.bind.address.
Note:
IPv6 address cannot be parsed with JBossRemoting 2.2.1.GA bundled in 4.2.1.GA. IPv6 parsing needs updated version of JBossRemoting.
http://jira.jboss.com/jira/browse/JBREM-645
--
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
18 years