Re: Unable to find [jdbc].

[Jerry Malcolm]

Found it.  Details if anybody wants to dig into it

The 30 second intervals should have given me a clue.  We are running 
multiple server instances in a cluster that have a health check for each 
server instance.  A pre-defined URL is called on each server instance 
every 30 seconds.  But since it needs to target specific instances, it 
can't simply use the host name.  It has to send the request using the IP 
address instead.  This means Tomcat default host will handle it.  The 
Catalina context file for default host is used instead of the normal 
host name context file, and the default host file didn't have all of the 
required dataSource names used by the test URL.  The real problem was 
that this slipped by for a while and wasn't failing the health check as 
it should have.  I just accidentally saw all the errors in the logs 
while looking for something else.  Anyway, problem solved. (At least 
THIS one was solved :-) )


Jerry

On 6/27/2023 3:41 PM, Jerry Malcolm wrote:
All of a sudden I started getting a NameNotFoundException when I'm 
trying to resolve a dataSource name.   But it comes and goes on all of 
my dataSource names.  The log below was from about a minute.  The only 
thing I could find in a google search for "Unable to find [jdbc]"  
says my configuration is wrong and proceeds to explain how to set up a 
datasource.  My datasources have been set up for several years, 
correctly as far as I know. They were all working fine until a couple 
of days ago.  And now they fail for 30 seconds, work for 30 seconds, 
and fail again for 30 seconds.


This is a pretty critical problem.  I've spent several hours trying to 
figure out what could be causing it.  It's failing on:


 ds = (DataSource)envContext.lookup( dataSourceName );

The datasource is defined in a context file in Catalina folder:

   type="javax.sql.DataSource" />


And the global resource is defined in /conf/server.xml.

Tomcat 9.0.53 running on Java 11, AWS Linux2, connecting to an AWS 
MySQL RDS.


I haven't been playing with dataSources in months.  I'm at a loss.  
Not a fan of random problems that just appear  Any help you can 
offer to assist me in figuring this out and getting it resolved will 
be greatly appreciated.


Jerry


   ---javax.naming.NameNotFoundException: Name [jdbc/idmanager2] is 
not bound in this Context. Unable to find [jdbc].
    ---javax.naming.NameNotFoundException: Name [jdbc/idmanager2] is 
not bound in this Context. Unable to find [jdbc].
    ---javax.naming.NameNotFoundException: Name [jdbc/idmanager2] is 
not bound in this Context. Unable to find [jdbc].
2023-06-27 20:17:02.924637 Successful - DBData.getConnection( 
jdbc/idmanager2 )
2023-06-27 20:17:02.925252 Successful - DBData.getConnection( 
jdbc/idmanager2 )
2023-06-27 20:17:03.911673 Successful - DBData.getConnection( 
jdbc/idmanager2 )
2023-06-27 20:17:03.981999 Successful - DBData.getConnection( 
jdbc/idmanager2 )
2023-06-27 20:17:04.001715 Successful - DBData.getConnection( 
jdbc/idmanager2 )
2023-06-27 20:17:04.80616 Successful - DBData.getConnection( 
jdbc/idmanager2 )
    ---javax.naming.NameNotFoundException: Name [jdbc/idmanager2] is 
not bound in this Context. Unable to find [jdbc].
    ---javax.naming.NameNotFoundException: Name [jdbc/idmanager2] is 
not bound in this Context. Unable to find [jdbc].
    ---javax.naming.NameNotFoundException: Name [jdbc/idmanager2] is 
not bound in this Context. Unable to find [jdbc].
    ---javax.naming.NameNotFoundException: Name [jdbc/idmanager2] is 
not bound in this Context. Unable to find [jdbc].
    ---javax.naming.NameNotFoundException: Name [jdbc/idmanager2] is 
not bound in this Context. Unable to find [jdbc].
    ---javax.naming.NameNotFoundException: Name [jdbc/idmanager2] is 
not bound in this Context. Unable to find [jdbc].



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Unable to find [jdbc].

[Jerry Malcolm]

All of a sudden I started getting a NameNotFoundException when I'm 
trying to resolve a dataSource name.   But it comes and goes on all of 
my dataSource names.  The log below was from about a minute.  The only 
thing I could find in a google search for "Unable to find [jdbc]"  says 
my configuration is wrong and proceeds to explain how to set up a 
datasource.  My datasources have been set up for several years, 
correctly as far as I know. They were all working fine until a couple of 
days ago.  And now they fail for 30 seconds, work for 30 seconds, and 
fail again for 30 seconds.


This is a pretty critical problem.  I've spent several hours trying to 
figure out what could be causing it.  It's failing on:


 ds = (DataSource)envContext.lookup( dataSourceName );

The datasource is defined in a context file in Catalina folder:

   type="javax.sql.DataSource" />


And the global resource is defined in /conf/server.xml.

Tomcat 9.0.53 running on Java 11, AWS Linux2, connecting to an AWS MySQL 
RDS.


I haven't been playing with dataSources in months.  I'm at a loss.  Not 
a fan of random problems that just appear  Any help you can offer to 
assist me in figuring this out and getting it resolved will be greatly 
appreciated.


Jerry


   ---javax.naming.NameNotFoundException: Name [jdbc/idmanager2] is not 
bound in this Context. Unable to find [jdbc].
    ---javax.naming.NameNotFoundException: Name [jdbc/idmanager2] is 
not bound in this Context. Unable to find [jdbc].
    ---javax.naming.NameNotFoundException: Name [jdbc/idmanager2] is 
not bound in this Context. Unable to find [jdbc].
2023-06-27 20:17:02.924637 Successful - DBData.getConnection( 
jdbc/idmanager2 )
2023-06-27 20:17:02.925252 Successful - DBData.getConnection( 
jdbc/idmanager2 )
2023-06-27 20:17:03.911673 Successful - DBData.getConnection( 
jdbc/idmanager2 )
2023-06-27 20:17:03.981999 Successful - DBData.getConnection( 
jdbc/idmanager2 )
2023-06-27 20:17:04.001715 Successful - DBData.getConnection( 
jdbc/idmanager2 )
2023-06-27 20:17:04.80616 Successful - DBData.getConnection( 
jdbc/idmanager2 )
    ---javax.naming.NameNotFoundException: Name [jdbc/idmanager2] is 
not bound in this Context. Unable to find [jdbc].
    ---javax.naming.NameNotFoundException: Name [jdbc/idmanager2] is 
not bound in this Context. Unable to find [jdbc].
    ---javax.naming.NameNotFoundException: Name [jdbc/idmanager2] is 
not bound in this Context. Unable to find [jdbc].
    ---javax.naming.NameNotFoundException: Name [jdbc/idmanager2] is 
not bound in this Context. Unable to find [jdbc].
    ---javax.naming.NameNotFoundException: Name [jdbc/idmanager2] is 
not bound in this Context. Unable to find [jdbc].
    ---javax.naming.NameNotFoundException: Name [jdbc/idmanager2] is 
not bound in this Context. Unable to find [jdbc].



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 10.1.x: Using CoyoteInputStream to read a Chunked Transfer Encoding (CTE) stream, manually, skiping ChunkedInputFilter

[Daniel Andres Pelaez Lopez]

El mar, 27 jun 2023 a las 13:48, Christopher Schultz (<
ch...@christopherschultz.net>) escribió:

> Daniel,
>
> On 6/27/23 12:56, Daniel Andres Pelaez Lopez wrote:
> > Christopher,
> >
> > El mar, 27 jun 2023 a las 9:33, Christopher Schultz (<
> > ch...@christopherschultz.net>) escribió:
> >
> >> Daniel,
> >>
> >> On 6/26/23 16:15, Daniel Andres Pelaez Lopez wrote:
> >>> El lun, 26 jun 2023 a las 14:53, Mark Thomas ()
> >> escribió:
> >>>
>  On 26/06/2023 20:34, Christopher Schultz wrote:
> > Daniel,
> >
> > On 6/26/23 12:47, Daniel Andres Pelaez Lopez wrote:
> >> Hi Tomcat community,
> >>
> >> I have a requirement where we want to manually decode a Chunked
> >> Transfer
> >> Encoding (CTE) stream using CoyoteInputStream to have access to the
>  chunk
> >> size. This means I want to use CoyoteInputStream.read method and get
> >> the
> >> whole CTE bytes. Saying it in another way: we want to decode the CTE
> >> at
> >> hand skipping Tomcat defaults.
> >
> > Dumb question: why?
> 
>  Not a dumb question at all. It is the key question. I'm curious as to
>  what the answer is.
> 
>  Mark
> 
> 
> >>> Not dumb question at all. Let me expand the use case: we are working on
> >> an
> >>> HTTP origin (Tomcat) for video streaming using HLS and DASH. Our video
> >>> packager generates video segments of X size, and each segment is also
> >>> divided into fragments (CMAF). The segment size is fixed, but the
> >> fragment
> >>> size is variable. Our packager transfers the segment meanwhile it
> >> generates
> >>> it, a fragment at the time (a chunk), in a CTE, to the HTTP origin
> >>> (Tomcat). Now, video players want to download the segment, but as for
> the
> >>> HLS spec, we require to transfer the segment to the video player, as we
> >>> received, a fragment a the time. To be able of sending a fragment at
> the
> >>> time, we need to know its size, which is implicit inside the CTE (each
> >>> chunk declares the chunk size).
> >>>
> >>> Our current implementation sends the segment using CTE to the video
> >>> players, but we cannot guarantee we are sending a fragment by chunk.
> >>>
> >>> This is why having access to each chunk and its size will help us.
> >>
> >> Thanks for the details. I think I've got it, but I want to clarify a
> >> little bit.
> >>
> >> Is your video-chunk-generator producing anything HTTP-related? It almost
> >> sounds like Tomcat is a reverse-proxy and your video-generator is the
> >> origin. Maybe you are just generating byte[] from the video-generator?
> >>
> >> Or maybe your video-generator is UPLOADING the chunks to the HTTP
> >> server? It's not entirely clear to me, and the details matter.
> >>
> >
> > Thanks for staying in the conversation.
> >
> > The packager (video-chunk-generator) sends an HTTP PUT with
> > Transfer-Encoding: chunked header, the content is a video segment, where
> > each chunk is a fragment, so, yes, the video-chunk-generator uploads the
> > segment in chunks to the Tomcat server (origin)
> >
> > Sorry for the confusion regarding the word "origin", that is a video
> > streaming term that doesn't matter for the question.
>
> Yes, that's important information to have: in HTTPD, the "origin" is the
> web server which actually has the desired resource. Contrast that with a
> reverse proxy, etc.
>
> >> It sounds like you are trying to optimize things such that video-chunk
> >> size ends up being equal to the HTTP-chunk size. Is that the real goal?
> >>
> >
> > The video-chunk-generator does it for us, it sends each video fragment as
> > an HTTP chunk. What we want to optimize is not the transfer from the
> > video-chunk-generator to the server, but from the server to its clients.
> > Clients will do an HTTP GET against the server to grab the segment, that
> > GET we want to optimize in a way that we keep the fragment-by-chunk
> > strategy, using Transfer-Encoding: chunked. This is why, accessing each
> > chunk size when the video-chunk-generator does the PUT, and saving that
> > info in the server, we can use it when clients do a GET, to assure we
> > transfer the same way we received.
>
> Is there no way to observe the video-chunk-size by looking at the raw
> bytes of the video file itself? Take the MP3 audio format, with which
> I'm more familiar. MP3 frame lengths can be computed based upon some
> information at the start of each frame including the version number, bit
> rate, sample rate, etc. So by reading a few bytes into the file, you
> know how big each chunk would need to be. Then you can bush the bytes
> and go to the next chunk, etc.
>
> If you can do that with your files, there is no reason to record the
> chunk-sizes that you got at the time of upload unless you just want the
> download to be as absolutely screaming-fast as possible and you don't
> want to perform any mathematical operations at all during the download
> (though you will presumably have to read a file from 

Re: Tomcat 10.1.x: Using CoyoteInputStream to read a Chunked Transfer Encoding (CTE) stream, manually, skiping ChunkedInputFilter

[Christopher Schultz]

Daniel,

On 6/27/23 12:56, Daniel Andres Pelaez Lopez wrote:

Christopher,

El mar, 27 jun 2023 a las 9:33, Christopher Schultz (<
ch...@christopherschultz.net>) escribió:


Daniel,

On 6/26/23 16:15, Daniel Andres Pelaez Lopez wrote:

El lun, 26 jun 2023 a las 14:53, Mark Thomas ()

escribió:



On 26/06/2023 20:34, Christopher Schultz wrote:

Daniel,

On 6/26/23 12:47, Daniel Andres Pelaez Lopez wrote:

Hi Tomcat community,

I have a requirement where we want to manually decode a Chunked

Transfer

Encoding (CTE) stream using CoyoteInputStream to have access to the

chunk

size. This means I want to use CoyoteInputStream.read method and get

the

whole CTE bytes. Saying it in another way: we want to decode the CTE

at

hand skipping Tomcat defaults.


Dumb question: why?


Not a dumb question at all. It is the key question. I'm curious as to
what the answer is.

Mark



Not dumb question at all. Let me expand the use case: we are working on

an

HTTP origin (Tomcat) for video streaming using HLS and DASH. Our video
packager generates video segments of X size, and each segment is also
divided into fragments (CMAF). The segment size is fixed, but the

fragment

size is variable. Our packager transfers the segment meanwhile it

generates

it, a fragment at the time (a chunk), in a CTE, to the HTTP origin
(Tomcat). Now, video players want to download the segment, but as for the
HLS spec, we require to transfer the segment to the video player, as we
received, a fragment a the time. To be able of sending a fragment at the
time, we need to know its size, which is implicit inside the CTE (each
chunk declares the chunk size).

Our current implementation sends the segment using CTE to the video
players, but we cannot guarantee we are sending a fragment by chunk.

This is why having access to each chunk and its size will help us.


Thanks for the details. I think I've got it, but I want to clarify a
little bit.

Is your video-chunk-generator producing anything HTTP-related? It almost
sounds like Tomcat is a reverse-proxy and your video-generator is the
origin. Maybe you are just generating byte[] from the video-generator?

Or maybe your video-generator is UPLOADING the chunks to the HTTP
server? It's not entirely clear to me, and the details matter.



Thanks for staying in the conversation.

The packager (video-chunk-generator) sends an HTTP PUT with
Transfer-Encoding: chunked header, the content is a video segment, where
each chunk is a fragment, so, yes, the video-chunk-generator uploads the
segment in chunks to the Tomcat server (origin)

Sorry for the confusion regarding the word "origin", that is a video
streaming term that doesn't matter for the question.


Yes, that's important information to have: in HTTPD, the "origin" is the 
web server which actually has the desired resource. Contrast that with a 
reverse proxy, etc.



It sounds like you are trying to optimize things such that video-chunk
size ends up being equal to the HTTP-chunk size. Is that the real goal?



The video-chunk-generator does it for us, it sends each video fragment as
an HTTP chunk. What we want to optimize is not the transfer from the
video-chunk-generator to the server, but from the server to its clients.
Clients will do an HTTP GET against the server to grab the segment, that
GET we want to optimize in a way that we keep the fragment-by-chunk
strategy, using Transfer-Encoding: chunked. This is why, accessing each
chunk size when the video-chunk-generator does the PUT, and saving that
info in the server, we can use it when clients do a GET, to assure we
transfer the same way we received.


Is there no way to observe the video-chunk-size by looking at the raw 
bytes of the video file itself? Take the MP3 audio format, with which 
I'm more familiar. MP3 frame lengths can be computed based upon some 
information at the start of each frame including the version number, bit 
rate, sample rate, etc. So by reading a few bytes into the file, you 
know how big each chunk would need to be. Then you can bush the bytes 
and go to the next chunk, etc.


If you can do that with your files, there is no reason to record the 
chunk-sizes that you got at the time of upload unless you just want the 
download to be as absolutely screaming-fast as possible and you don't 
want to perform any mathematical operations at all during the download 
(though you will presumably have to read a file from storage, which has 
a much higher cost than a little bit of math IMHO).


Let's assume you CAN determine chunk-size from your source file. You can 
get Tomcat to chunk your file the same way just like this:


public void goGet(HttpServletRequest request, HttpServletResponse 
response) throws IOException {


  response.setHeader("Transfer-Encoding", "chunked");
  response.setBufferSize(MAXIMUM_VIDEO_FRAME_SIZE); // This is important

  InputStream video = ...; // You figure this out
  OutputStream out = response.getOutputStream();

  boolean eof = false;

  byte[] 

Re: Tomcat 10.1.x: Using CoyoteInputStream to read a Chunked Transfer Encoding (CTE) stream, manually, skiping ChunkedInputFilter

[Daniel Andres Pelaez Lopez]

Christopher,

El mar, 27 jun 2023 a las 9:33, Christopher Schultz (<
ch...@christopherschultz.net>) escribió:

> Daniel,
>
> On 6/26/23 16:15, Daniel Andres Pelaez Lopez wrote:
> > El lun, 26 jun 2023 a las 14:53, Mark Thomas ()
> escribió:
> >
> >> On 26/06/2023 20:34, Christopher Schultz wrote:
> >>> Daniel,
> >>>
> >>> On 6/26/23 12:47, Daniel Andres Pelaez Lopez wrote:
>  Hi Tomcat community,
> 
>  I have a requirement where we want to manually decode a Chunked
> Transfer
>  Encoding (CTE) stream using CoyoteInputStream to have access to the
> >> chunk
>  size. This means I want to use CoyoteInputStream.read method and get
> the
>  whole CTE bytes. Saying it in another way: we want to decode the CTE
> at
>  hand skipping Tomcat defaults.
> >>>
> >>> Dumb question: why?
> >>
> >> Not a dumb question at all. It is the key question. I'm curious as to
> >> what the answer is.
> >>
> >> Mark
> >>
> >>
> > Not dumb question at all. Let me expand the use case: we are working on
> an
> > HTTP origin (Tomcat) for video streaming using HLS and DASH. Our video
> > packager generates video segments of X size, and each segment is also
> > divided into fragments (CMAF). The segment size is fixed, but the
> fragment
> > size is variable. Our packager transfers the segment meanwhile it
> generates
> > it, a fragment at the time (a chunk), in a CTE, to the HTTP origin
> > (Tomcat). Now, video players want to download the segment, but as for the
> > HLS spec, we require to transfer the segment to the video player, as we
> > received, a fragment a the time. To be able of sending a fragment at the
> > time, we need to know its size, which is implicit inside the CTE (each
> > chunk declares the chunk size).
> >
> > Our current implementation sends the segment using CTE to the video
> > players, but we cannot guarantee we are sending a fragment by chunk.
> >
> > This is why having access to each chunk and its size will help us.
>
> Thanks for the details. I think I've got it, but I want to clarify a
> little bit.
>
> Is your video-chunk-generator producing anything HTTP-related? It almost
> sounds like Tomcat is a reverse-proxy and your video-generator is the
> origin. Maybe you are just generating byte[] from the video-generator?
>
> Or maybe your video-generator is UPLOADING the chunks to the HTTP
> server? It's not entirely clear to me, and the details matter.
>

Thanks for staying in the conversation.

The packager (video-chunk-generator) sends an HTTP PUT with
Transfer-Encoding: chunked header, the content is a video segment, where
each chunk is a fragment, so, yes, the video-chunk-generator uploads the
segment in chunks to the Tomcat server (origin)

Sorry for the confusion regarding the word "origin", that is a video
streaming term that doesn't matter for the question.


> It sounds like you are trying to optimize things such that video-chunk
> size ends up being equal to the HTTP-chunk size. Is that the real goal?
>

The video-chunk-generator does it for us, it sends each video fragment as
an HTTP chunk. What we want to optimize is not the transfer from the
video-chunk-generator to the server, but from the server to its clients.
Clients will do an HTTP GET against the server to grab the segment, that
GET we want to optimize in a way that we keep the fragment-by-chunk
strategy, using Transfer-Encoding: chunked. This is why, accessing each
chunk size when the video-chunk-generator does the PUT, and saving that
info in the server, we can use it when clients do a GET, to assure we
transfer the same way we received.


>
> In that case, you want to force the chunk size to something specific,
> rather than just trying to see what the chunk size is.
>
> How you do that depends on whether your video-generator is sending data
> in the *request entity* in e.g. PUT or POST or if you are fetching the
> data in a *response entity*.
>
> I *think* you want to inspect chunk-size of an upload-to-Tomcat, but I
> want to be sure. Might this be easier to do on the client to force a
> certain chunk-size?
>

You are right, we want to inspect the chunk-size of an upload to Tomcat. We
have no control over the video-chunk-generator, so, the only way to know
the fragment/chunk size they are sending is by inspecting the CTE.


>
> Finally... for video, perhaps a Websocket connection would be better
> since there is less protocol-overhead once the ws connection is
> established?
>

True, but the video-chunk-generator only offers two ways of transfer: HTTP
PUT or writing to disk. The second option was discarded as we will need to
listen to file system events and do some magic there, which we don't need
to do for the HTTP PUT, as the protocol/Tomcat guarantee when the transfer
starts and ends.


>
>  The current flow from the point of view of CoyoteInputStream is:
>  CoyoteInputStream.read -> Request.read -> ChunkedInputFilter.read.
> 
>  ChunkedInputFilter handles the CTE decoding and the read method 

Re: problem with SSL connection java.security.NoSuchAlgorithmException: Error constructing implementation

[Christopher Schultz]

Ivano,

On 6/27/23 09:15, Ivano Luberti wrote:
We had another Linux server that should have been identical to the one 
where the problem was occuring. Tested the same software on that without 
the issue.


So we cloned the latter and replaced the former.

>

Now everything works as expected.


Hah.

Before the replacement we tried to find  out any difference between the 
two servers, especially with regard to JDK and Tomcat installations but 
to no avail: they looked identical file by file, not only by version. I 
had supposed the cacert file was corrupted but it was identical to the 
one on the working machine.


Having found a practical solution we have decided to give up investigating.

Thank you again to you and the other that paid attention to my issue.


Of course.

Someone recently posted a similar issue that has no explanation which 
magically went-away after (essentially) re-building the server. There 
was nothing specific that could be pointed-to as a likely source of the 
problem, but now it's just /gone/.


It's not entirely satisfying from a "what if it happens again" 
perspective, but "you can't argue with results."


-chris


Il 26/06/2023 18:50, Christopher Schultz ha scritto:

Ivano,

On 6/8/23 06:10, Ivano Luberti wrote:

Hi, all I have the following problem.


[snip]

My guess is that looking at the code in this general area would be 
helpful. If you are able to add debug logging in there to spoit-out 
some of the crypto configuration being used, I'm sure it would help:



it.sella.ecomm.WSCryptDecryptStub,encrypt,197
it.archicoop.met.sistemapagamento.bancasella.wscryptdecryptclient.WSClient,encrypt,61
it.archimede.met.backoffice.pagamento.GestionePagamento,encrypt,75
it.archimede.met.turisti.servlet.NuovoOrdineAcquista,encrypt,379


Sorry, I don't think anybody here will be able to help much further 
without a lot more information.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 10.1.x: Using CoyoteInputStream to read a Chunked Transfer Encoding (CTE) stream, manually, skiping ChunkedInputFilter

[Christopher Schultz]

Daniel,

On 6/26/23 16:15, Daniel Andres Pelaez Lopez wrote:

El lun, 26 jun 2023 a las 14:53, Mark Thomas () escribió:


On 26/06/2023 20:34, Christopher Schultz wrote:

Daniel,

On 6/26/23 12:47, Daniel Andres Pelaez Lopez wrote:

Hi Tomcat community,

I have a requirement where we want to manually decode a Chunked Transfer
Encoding (CTE) stream using CoyoteInputStream to have access to the

chunk

size. This means I want to use CoyoteInputStream.read method and get the
whole CTE bytes. Saying it in another way: we want to decode the CTE at
hand skipping Tomcat defaults.


Dumb question: why?


Not a dumb question at all. It is the key question. I'm curious as to
what the answer is.

Mark



Not dumb question at all. Let me expand the use case: we are working on an
HTTP origin (Tomcat) for video streaming using HLS and DASH. Our video
packager generates video segments of X size, and each segment is also
divided into fragments (CMAF). The segment size is fixed, but the fragment
size is variable. Our packager transfers the segment meanwhile it generates
it, a fragment at the time (a chunk), in a CTE, to the HTTP origin
(Tomcat). Now, video players want to download the segment, but as for the
HLS spec, we require to transfer the segment to the video player, as we
received, a fragment a the time. To be able of sending a fragment at the
time, we need to know its size, which is implicit inside the CTE (each
chunk declares the chunk size).

Our current implementation sends the segment using CTE to the video
players, but we cannot guarantee we are sending a fragment by chunk.

This is why having access to each chunk and its size will help us.


Thanks for the details. I think I've got it, but I want to clarify a 
little bit.


Is your video-chunk-generator producing anything HTTP-related? It almost 
sounds like Tomcat is a reverse-proxy and your video-generator is the 
origin. Maybe you are just generating byte[] from the video-generator?


Or maybe your video-generator is UPLOADING the chunks to the HTTP 
server? It's not entirely clear to me, and the details matter.


It sounds like you are trying to optimize things such that video-chunk 
size ends up being equal to the HTTP-chunk size. Is that the real goal?


In that case, you want to force the chunk size to something specific, 
rather than just trying to see what the chunk size is.


How you do that depends on whether your video-generator is sending data 
in the *request entity* in e.g. PUT or POST or if you are fetching the 
data in a *response entity*.


I *think* you want to inspect chunk-size of an upload-to-Tomcat, but I 
want to be sure. Might this be easier to do on the client to force a 
certain chunk-size?


Finally... for video, perhaps a Websocket connection would be better 
since there is less protocol-overhead once the ws connection is established?



The current flow from the point of view of CoyoteInputStream is:
CoyoteInputStream.read -> Request.read -> ChunkedInputFilter.read.

ChunkedInputFilter handles the CTE decoding and the read method only
returns the chunks, with no other information, like chunk size.

I found that the method Request.setInputBuffer might allow to set a
different InputBuffer implementation, for instance, the
IdentityInputFilter, which I understand returns all the stream bytes,
with
no decoding. However, not sure if this is the right way and which
consequences might have.

I would like to know if there are other ways to override the CTE
behavior,
any help would be appreciated.


A problem I can see is that you are working with a blocking streaming
interface e.g. read(byte[]) and you also want to get the chunk size.
When? The chunk-size can change for every chunk, so if you call
getChunkSize() before the read() and after the read(), they may be
different if the read() returns data from multiple chunks. It may have
changed multiple times between read() was called and when it completed.

If you want to always size byte byte[] to read full-chunks at once ... I
guess I would again ask "why?"

Would it be sufficient for ChunkedInputFilter to maybe send an
event-notification each time a chunk boundary was crossed? For example:

public interface ChunkListener {
public void chunkStarted(ChunkedInputFilter source, long offset, long
length);
public void chunkFinished(ChunkedInputFilter source, long offset,
long length);
}

Then, every time the Filter begins or ends a chunk it could notify your
code and you can do whatever you want with that information.



You might be able to subclass the (somewhat confusingly-named)

ChunkInputFilter and bolt-on your own logic like what I have above.




Yes, a listener like that looks great. Any more clues on how to inject my
own ChunkInputFilter implementation in Tomcat configuration? seems quite
hard to do it well.  Also, the listener must be linked by HTTP request.


I think doing so would require some internal support for messing-around 
with the chain of objects that handle the 

Re: problem with SSL connection java.security.NoSuchAlgorithmException: Error constructing implementation

[Ivano Luberti]

Hi Chris, thank you for your dedication.

We had another Linux server that should have been identical to the one 
where the problem was occuring. Tested the same software on that without 
the issue.


So we cloned the latter and replaced the former.

Now everything works as expected.

Before the replacement we tried to find  out any difference between the 
two servers, especially with regard to JDK and Tomcat installations but 
to no avail: they looked identical file by file, not only by version. I 
had supposed the cacert file was corrupted but it was identical to the 
one on the working machine.


Having found a practical solution we have decided to give up investigating.

Thank you again to you and the other that paid attention to my issue.





Il 26/06/2023 18:50, Christopher Schultz ha scritto:

Ivano,

On 6/8/23 06:10, Ivano Luberti wrote:

Hi, all I have the following problem.


[snip]

My guess is that looking at the code in this general area would be 
helpful. If you are able to add debug logging in there to spoit-out 
some of the crypto configuration being used, I'm sure it would help:



it.sella.ecomm.WSCryptDecryptStub,encrypt,197
it.archicoop.met.sistemapagamento.bancasella.wscryptdecryptclient.WSClient,encrypt,61 


it.archimede.met.backoffice.pagamento.GestionePagamento,encrypt,75
it.archimede.met.turisti.servlet.NuovoOrdineAcquista,encrypt,379


Sorry, I don't think anybody here will be able to help much further 
without a lot more information.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


--

Archimede Informatica tratta i dati personali in conformità a quanto
stabilito dal Regolamento UE n. 2016/679 (GDPR) e dal D. Lgs. 30 giugno 
2003 n. 196

per come modificato dal D.Lgs. 10 agosto 2018 n. 101.
Informativa completa 



dott. Ivano Mario Luberti

Archimede Informatica società cooperativa a r. l.
Via Gereschi 36, 56127 Pisa

tel.: +39 050/580959 | fax: +39 050/8932061

web: www.archicoop.it
linkedin: www.linkedin.com/in/ivanoluberti
facebook: www.facebook.com/archimedeinformaticapisa/